Перевод краткого руководства от UX-писателя BBC Эми Лик.
Ошибки на сайте возникают и по вине системы, а иногда и по вине пользователя. Чтобы их было легко исправить, важно писать чёткие, логичные и доступные сообщения.
Определите, с какой ошибкой столкнулся пользователь
Прежде чем составлять сообщение, убедитесь, что знаете ответы на эти вопросы:
- Что произошло?
- Как это случилось?
- Как это исправить?
- Ошибся пользователь, система или все вместе?
- Можно ли изменить текст этого сообщения? Операционная система может контролировать некоторые сообщения об ошибках.
Структура текста
Чтобы исправить ошибку, сначала нужно узнать, в чём она состоит. Сообщение будет выглядеть примерно так: ошибка → как её исправить.
Довольно простая структура. Вот пример реального сообщения об ошибке в одну строчку.
Бывает, система не может указать, что именно произошло.
В примере ниже мы специально описываем ошибку в общих чертах. Лучшее, что можно сделать при проблемах с интернетом, — подсказать пользователю, как он может всё исправить.
Пишите коротко и ясно
Нужно помочь пользователям быстро исправить ошибку, чтобы они могли дальше заниматься своими делами.
Сообщение должно быть кратким и лаконичным. Избавьтесь от лишних слов, оставьте только нужные. Главное — не перестарайтесь: краткость не должна ставить под угрозу ясность сообщения. Не вырезайте из текста важные детали.
Системная ошибка
Если ошибка произошла по вине системы, извинитесь перед пользователем. Но если в этом виноват пользователь — будьте аккуратны. Извинения звучат неискренне там, где им не место. К тому же неуместные извинения могут сбить с толку — пользователь подумает, что не виноват в ошибке, раз система говорит «простите».
Чтобы принять ответственность за случившееся, используйте активный залог. Пишите: «Мы не можем сохранить ваши изменения», а не «Ваши изменения не могут быть сохранены».
Ошибка пользователя
Иногда ошибки появляются по вине пользователя. Но сообщить об этом можно мягко и без осуждения.
В примере ниже сделали акцент на том, как исправить ситуацию, а не на забывчивости пользователя.
Пассивный залог удобно использовать, когда ошибка произошла по вине пользователя. Он поможет смягчить неприятную ситуацию, например, когда «Ваша карта была отклонена».
Используйте правильный тон
Тон сообщения будет зависеть от серьёзности ошибки. Мягкость в словах отлично подходит для мелких ошибок, но для более критических стоит подбирать слог построже.
Избегайте спецтерминов и всегда изъясняйтесь просто. Пользователь должен чувствовать, что вы стараетесь помочь ему и понятно объяснить, что делать. Помните, мы говорим с людьми, а не с машинами.
Пожалуйста, не пытайтесь умничать. Не время для шуток и креатива, когда у пользователя проблема. Шутки или креатив только испортят текст сообщения и усилят чувство разочарования.
Что случится, если нажать на кнопку
Для устранения некоторых ошибок могут потребоваться СТА-кнопка или ссылка. Иногда бывает нужна кнопка отмены.
Всегда объясняйте, что будет, если нажать на кнопку или ссылку. Их текст должен быть понятным, даже если прочитать его отдельно, вне сообщения об ошибке. Это поможет незрячим пользователям перемещаться по интерактивным элементам. Тем, кто бегло прочитал сообщение, тоже будет легче сориентироваться.
Не используйте просто слово «Ок». Что оно значит? С помощью «Ок» можно подтвердить отмену действия или его совершение. Сделайте так, чтобы пользователю было понятно, с чем он соглашается.
Время и место
Сообщения об ошибках должны принимать во внимание все действия пользователя. Время и место появления сообщения помогают понять, что произошло. Это помогает пользователю исправить ошибку.
- Что вызывало это сообщение?
- Когда оно появилось?
- Где появилось?
- Понятно ли, с чем оно связано?
Задавая эти вопросы, не забывайте, что есть пользователи с ограниченными возможностями. Это подталкивает к новым вопросам:
- Как мы можем помочь всем пользователям перейти к решению?
- Может ли ошибка слишком встревожить пользователя или быть навязчивой, появившись в этот конкретный момент?
- Как связать сообщение с соответствующим разделом визуально и не визуально?
Помните, что сообщения об ошибках — не барьеры. Они существуют, чтобы расширять возможности, успокаивать и направлять пользователей.
Ключевые рекомендации
- Определите, с какой ошибкой столкнулся пользователь и как её исправить.
- Пишите коротко и ясно.
- Используйте нужный тон и только уместные извинения.
- Дайте понять, что будет, если нажать на кнопку или ссылку.
- Учитывайте время и место появления сообщения. Не забывайте про то, как воспримут его пользователи с ограниченными возможностями.
Бестолковые сообщения об ошибках: вносим ясность
Время на прочтение
4 мин
Количество просмотров 6.9K
Попробуйте вспомнить, какие оригинальные и необычные сообщения об ошибках вам выдавали многочисленные программы и приложения, которыми вы пользуетесь. Наверняка у каждого из вас найдётся пара забавных примеров таких сообщений. В моём личном рейтинге на данный момент безусловный лидер — «Метод вернул что-то не то». Если существует шкала информативности сообщений, то приведённый пример по этой шкале стремится к нулю.
Здесь система, по сути, сообщает нам, что произошла ошибка. Больше никакой информации из этого текста мы не получим. Разве что узнаем, что где-то в недрах самой системы существует какой-то метод, который что-то не то вернул. Ценность этого знания для обычного пользователя нулевая.
Можно предположить, что этот текст — артефакт, оставшийся от процесса тестирования очередной функциональности. Некий флаг, оставленный разработчиком на этапе альфа-тестирования. Для программиста он явно имел какой-то смысл, но для пользователя — совершенно бесполезен.
К сожалению, подобные сообщения в наших программах и системах — не редкость. Разработчики оставляют в коде технические сообщения, а иногда просто ленятся написать хорошее информативное описание ошибки. А ведь такой текст не только помог бы пользователю в работе, но и снизил бы количество обращений в службу поддержки. Если пользователю внятно объяснить, что он сделал не так и как сделать правильно, то он наверняка справится с проблемой самостоятельно.
Каким же должно быть идеальное сообщение об ошибке?
5 основных правил
В книге Сьюзан Уэйншенк «100 главных принципов дизайна» приведены основные правила написания информативного и полезного сообщения об ошибке:
-
Расскажите пользователю, что он сделал.
-
Объясните проблему.
-
Объясните, как исправить ошибку.
-
Используйте активный, а не пассивный залог.
-
Приведите пример.
В книге есть пример того, как не надо писать сообщения об ошибке:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
После варианта «Метод вернул что-то не то» даже такое сообщение может показаться довольно информативным. Однако в нём есть что улучшить. Но для начала давайте в порядке эксперимента попробуем его ухудшить — разберёмся, как не надо писать сообщения об ошибках.
«Вы хотите отправить разработчикам отчёт об ошибке в приложении?»
«Ok»
«Ну и ябеда!»
bash.im
Нам не привыкать — у нас за плечами многолетний опыт общения с разномастными продуктами отечественного софтостроения. Давайте уберём конкретику вовсе:
Счёт не может быть оплачен. Введены неправильные данные.
Чтобы ещё больше запутать пользователя, скроем от него причину ошибки:
Счёт не может быть оплачен.
Теперь приблизимся вплотную к нашему почти нулевому варианту:
Ошибка выполнения метода bill_payment.
Дальше для достижения антиидеала нам остаётся только убрать название метода и творчески преобразовать текст:
Неизвестная ошибка.
Интересно, не возникло ли у вас чувство дежавю, когда вы читали примеры в этом подразделе?
Добавляем информацию
В случае возникновения критической ошибки обновления:
1. Установите причину ошибки.
2. Устраните причину ошибки.
Документация Microsoft
Теперь давайте двигаться в другую сторону по нашей шкале — будем постепенно улучшать текст сообщения, руководствуясь правилами Сьюзан Уэйншенк.
Напомню исходный вариант сообщения из книги:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Для начала преобразуем исходный текст, чтобы его легче было воспринимать:
#402: Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Теперь расскажем пользователю, что он сделал не так:
#402: Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Выделим суть проблемы в отдельное предложение и явно объясним пользователю, что он должен сделать, чтобы её решить.
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Измените дату платежа так, чтобы она была позднее даты создания счёта.
Наконец, приведём конкретный пример. В данном случае нам известны даты и мы их можем использовать в тексте:
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа 25.07.2021 — она раньше, чем дата создания счёта 29.07.2021. Измените дату платежа так, чтобы она была позднее даты создания счёта 29.07.2021. Например, 30.07.2021.
Мы существенно улучшили сообщение об ошибке — учли все правила и почти приблизились к идеалу. Но давайте поднимемся на уровень выше и подумаем, можно ли сделать так, чтобы ошибка не возникала вовсе.
Лучшее сообщение об ошибке
Ошибка выполнения метода: «Метод выполнился без ошибок».
Есть фразы, которые сразу хочется выписать на жёлтый стикер и приклеить где-то рядом с монитором. Одна из таких фраз: «Лучшее сообщение об ошибке — отсутствие сообщения об ошибке». Иными словами, часто бывает проще не допустить возможности возникновения ошибки, чем её описывать.
В нашем примере никто не мешает разработчику сделать две вещи:
-
При смене даты счёта очистить поле с датой платежа.
-
В интерфейсе запретить ввод даты платежа позже заданной даты счёта.
UPD: При этом неплохо бы подробно сообщить пользователю о причинах такого ограничения редактирования.
Эти незначительные изменения в коде позволят избежать ошибки вовсе. И не нужно будет ломать голову над текстом сообщения.
К сожалению, таким простым способом решить проблему удаётся не всегда. Мы не можем полностью обезопасить приложение от возникновения ошибок. Но в наших силах сделать сообщения об ошибках более информативными и полезными.
Статья была впервые опубликована на другом ресурсе 30 июля 2021.
Перевод краткого руководства от UX-писателя BBC Эми Лик.
Ошибки на сайте возникают и по вине системы, а иногда и по вине пользователя. Чтобы их было легко исправить, важно писать чёткие, логичные и доступные сообщения.
Определите, с какой ошибкой столкнулся пользователь
Прежде чем составлять сообщение, убедитесь, что знаете ответы на эти вопросы:
- Что произошло?
- Как это случилось?
- Как это исправить?
- Ошибся пользователь, система или все вместе?
- Можно ли изменить текст этого сообщения? Операционная система может контролировать некоторые сообщения об ошибках.
Структура текста
Чтобы исправить ошибку, сначала нужно узнать, в чём она состоит. Сообщение будет выглядеть примерно так: ошибка → как её исправить.
Довольно простая структура. Вот пример реального сообщения об ошибке в одну строчку.
Бывает, система не может указать, что именно произошло.
В примере ниже мы специально описываем ошибку в общих чертах. Лучшее, что можно сделать при проблемах с интернетом, — подсказать пользователю, как он может всё исправить.
Пишите коротко и ясно
Нужно помочь пользователям быстро исправить ошибку, чтобы они могли дальше заниматься своими делами.
Сообщение должно быть кратким и лаконичным. Избавьтесь от лишних слов, оставьте только нужные. Главное — не перестарайтесь: краткость не должна ставить под угрозу ясность сообщения. Не вырезайте из текста важные детали.
Системная ошибка
Если ошибка произошла по вине системы, извинитесь перед пользователем. Но если в этом виноват пользователь — будьте аккуратны. Извинения звучат неискренне там, где им не место. К тому же неуместные извинения могут сбить с толку — пользователь подумает, что не виноват в ошибке, раз система говорит «простите».
Чтобы принять ответственность за случившееся, используйте активный залог. Пишите: «Мы не можем сохранить ваши изменения», а не «Ваши изменения не могут быть сохранены».
Ошибка пользователя
Иногда ошибки появляются по вине пользователя. Но сообщить об этом можно мягко и без осуждения.
В примере ниже сделали акцент на том, как исправить ситуацию, а не на забывчивости пользователя.
Пассивный залог удобно использовать, когда ошибка произошла по вине пользователя. Он поможет смягчить неприятную ситуацию, например, когда «Ваша карта была отклонена».
Используйте правильный тон
Тон сообщения будет зависеть от серьёзности ошибки. Мягкость в словах отлично подходит для мелких ошибок, но для более критических стоит подбирать слог построже.
Избегайте спецтерминов и всегда изъясняйтесь просто. Пользователь должен чувствовать, что вы стараетесь помочь ему и понятно объяснить, что делать. Помните, мы говорим с людьми, а не с машинами.
Пожалуйста, не пытайтесь умничать. Не время для шуток и креатива, когда у пользователя проблема. Шутки или креатив только испортят текст сообщения и усилят чувство разочарования.
Что случится, если нажать на кнопку
Для устранения некоторых ошибок могут потребоваться СТА-кнопка или ссылка. Иногда бывает нужна кнопка отмены.
Всегда объясняйте, что будет, если нажать на кнопку или ссылку. Их текст должен быть понятным, даже если прочитать его отдельно, вне сообщения об ошибке. Это поможет незрячим пользователям перемещаться по интерактивным элементам. Тем, кто бегло прочитал сообщение, тоже будет легче сориентироваться.
Не используйте просто слово «Ок». Что оно значит? С помощью «Ок» можно подтвердить отмену действия или его совершение. Сделайте так, чтобы пользователю было понятно, с чем он соглашается.
Время и место
Сообщения об ошибках должны принимать во внимание все действия пользователя. Время и место появления сообщения помогают понять, что произошло. Это помогает пользователю исправить ошибку.
- Что вызывало это сообщение?
- Когда оно появилось?
- Где появилось?
- Понятно ли, с чем оно связано?
Задавая эти вопросы, не забывайте, что есть пользователи с ограниченными возможностями. Это подталкивает к новым вопросам:
- Как мы можем помочь всем пользователям перейти к решению?
- Может ли ошибка слишком встревожить пользователя или быть навязчивой, появившись в этот конкретный момент?
- Как связать сообщение с соответствующим разделом визуально и не визуально?
Помните, что сообщения об ошибках — не барьеры. Они существуют, чтобы расширять возможности, успокаивать и направлять пользователей.
Ключевые рекомендации
- Определите, с какой ошибкой столкнулся пользователь и как её исправить.
- Пишите коротко и ясно.
- Используйте нужный тон и только уместные извинения.
- Дайте понять, что будет, если нажать на кнопку или ссылку.
- Учитывайте время и место появления сообщения. Не забывайте про то, как воспримут его пользователи с ограниченными возможностями.
Каким должно быть сообщение об ошибке
Теперь можно рассказать,
каким должно быть сообщение об ошибке,
тем более, что ничего сложного в создании
идеального сообщения нет. Напротив, всё
очень просто. Идеальное сообщение об
ошибке должно отвечать всего на три
вопроса:
— В чем
заключается проблема?
— Как исправить
эту проблему сейчас?
— Как сделать
так, чтобы проблема не повторилась?
При этом отвечать на эти
вопросы нужно возможно более вежливым
и понятным пользователям языком. В
качестве примера идеального сообщения
об ошибке удобно взять какое-либо
существующее сообщение (из тех, которые
точно нельзя просто изъять из системы)
и попытаться это сообщение улучшить.
Например, попытаемся улучшить уже
упоминавшееся в предыдущей главе
сообщение о невозможности перезаписать
заблокированный файл.
Итак, старое сообщение об
ошибке гласило: «Не удается сохранить
файл «D:Только для чтения.doc». Файл с
этим именем уже существует и доступен
только для чтения. Сохраните файл под
другим именем или в другой папке». Это
довольно неплохое сообщение, во всяком
случае, оно гораздо лучше, чем «Указано
неверное число». Но и его можно улучшить.
Сначала надо разобраться, в каких случаях
оно появляется. Это несложно: оно может
появляться, если пользователь попытался
сохранить файл на компакт-диске, или же
пытается сохранить файл, незадолго
перед этим скопировав этот файл с
компакт-диска. Случаи, когда файл
заблокирован сознательно, в жизни редки,
так что их чаще всего можно не учитывать.
Главный враг – компакт-диск.
Тут возможно несколько
непротиворечащих друг другу решений.
Во-первых, просто можно блокировать
возможность что-либо записать на диске,
запись на который невозможна. Собственно
говоря, запись и так блокируется, но
сообщением об ошибке. А можно просто не
показывать диски, на которые нельзя
записывать, в окне записи, что эффективнее,
поскольку делает ошибку невозможной.
Во-вторых, как уже говорилось, можно
показывать файлы, защищенные от записи,
иначе, чем файлы незащищенные. Это будет
работать, но тоже неидеально. Что делать
пользователю, который всё-таки хочет
перезаписать файл? Сейчас в такой
ситуации приходится записывать файл
под новым именем, потом стирать старый,
а новому давать имя старого. Это и потери
времени и ошибочно стертые файлы (лучший
способ сделать так, чтобы пользователи
не стирали нужные файлы, заключается в
том, чтобы лишить пользователей
необходимости вообще что-либо стирать
в нормальном режиме работы).
Таким образом, сообщение
об ошибке должно стать не только
сообщением – оно должно позволять
разблокировать файлы, разблокировать
которые возможно (т.е. записанные не на
компакт-диске). Таким образом, получается,
что нужно сделать несколько изменений
в интерфейсе:
— Диски, на
которые ничего нельзя записать, не
показываются в диалоговом окне сохранения
файлов.
— Заблокированные
файлы на остальных дисках показываются
иначе, нежели файлы незаблокированные.
— При попытке
записать документ поверх заблокированного,
появляется сообщение об ошибке примерно
такого вида:
Рис. 15. Улучшенное сообщение
об ошибке. Обратите внимание, что кнопка
Закрыть выбрана
по умолчанию, чтобы снизить вероятность
перезаписи важных файлов. Конечно, лучше
всего было бы, чтобы ОС сама снимала с
копируемых с компакт-диска файлов метку
Read Only. Многие проблемы при этом бы
исчезли, поскольку защищенными от записи
остались только действительно важные
для ОС файлы.
Про этот пример осталось
сказать немного. Во-первых, никогда не
забывайте показывать текст сообщений
об ошибке техническому писателю.
Во-вторых, всемерно старайтесь делать
текст сообщения возможно более коротким.
В-третьих, диалоговое окно не самый
лучший способ показывать сообщения об
ошибках, во всяком случае, в ПО. Дело в
том, что в Windows появился элемент управления,
значительно лучше предназначенный для
показа сообщений. Называется этот
элемент весьма поэтично: пузырь
Рис. 16. Пузырь в его лучшем
проявлении (не обращайте внимания на
текст).
Пузырь, по сравнению с
диалоговым окном, имеет существенные
достоинства. Во-первых, он гораздо слабее
сбивает фокус внимания, нежели окно.
Во-вторых, чтобы закрыть пузырь,
пользователям не обязательно нажимать
на какую-либо кнопку, достаточно щелкнуть
мышью в любом месте экрана. В-третьих,
он не перекрывает значимую область
системы. В-четвертых, что самое главное,
он показывает, в каком именно элементе
управления была допущена ошибка. Все
это делает пузырь вещью совершенно
незаменимой. Я уверен, что через пару
лет 80 процентов всех сообщений об ошибках
будет появляться в пузырях.
К сожалению, пузыри имеют
и недостатки. Во-первых, в них не может
быть никаких элементов управления, так
что использовать пузырь в предыдущем
примере, например, было невозможно. В
Windows пузыри вообще реализованы довольно
бедно. Во-вторых, пузырей вообще нет в
интернете. Так что правило тут простое
–используйте пузыри всегда, когда это
возможно, и рыдайте, когда их нет.
Пароли.
Не только пароли, но сама по себе идея
секретности вызывает у пользователей
изжогу. Причем, что нечасто случается,
изжогу пароли вызывают не только у
какой-то отдельной группы пользователей,
такой как новички, а у всех. Объясняется
это просто – соблюдение секретности
требует от пользователей выполнения
действий, не приносящих пользы, но
уменьшающих потенциальный
вред. Человеческая
же природа такова, что потенциальное
кажется неважным, а вот действия, которые
приходится совершать, важны чрезвычайно.
В результате пароли не любит никто.
Разумеется, это не совсем
интерфейсная проблема, скорее политическая,
но она оказывает такое влияние на
результат, что обойти её невозможно.
Итак, пароли. Они имеют три принципиальных
проблемы. Во-первых, как уже было сказано,
пользователи не любят их вводить.
Во-вторых, пользователи либо забывают
пароли, либо пароли не работают, т.е.
ничего не защищают, поскольку пользователи
используют те пароли, которые они помнят
и которые, соответственно, непроблематично
подобрать. В-третьих, в интернете часто
происходит так, что пользователи, не
желая вводить пароль (и регистрироваться,
к слову говоря) так никогда не попадают
в главную часть сайта. В результате,
пароли есть явное и несомненное зло,
вопрос состоит лишь в том, как это зло
уменьшить.
Для этого есть несколько
путей. Во-первых, от них можно отказаться
вообще. Этот путь почти всегда
предпочтителен, проблема в том, что он
вызывает существенное отторжение у
сетевых администраторов (которые все
как один параноики). В самом деле, зачем
требовать от пользователя пароль, если
подобрать этот пароль злоумышленник
сможет без труда?
И обратно: поскольку
единственным способом создания
действительно трудноподбираемых паролей
является генератор случайных чисел,
каковые числа (символы, по необходимости)
невозможно запомнить, пользователи
либо будут записывать их на бумажке (в
этом случае пароли еще легче украсть),
либо будут забывать, что дорого стоит.
Я, например, вынужден пользоваться
четырьмя действительно случайными
паролями, причем тремя из них не реже
раза в неделю. При этом, несмотря на то,
что я пользуюсь этими паролями не менее
года, я не помню ни
одного. В результате,
все четыре пароля записаны у меня на
бумажке, которую увидеть может любой
(я её не прячу). Какая уж тут защита?
Рис. 17. Стандартный способ
человеколюбивого использования паролей:
слева во время регистрации, справа в
дальнейшей работе.
Этот метод хорош, когда дело
касается защиты информации. Однако
гораздо чаще, особенно в интернете,
важна не столько защита информации,
сколько идентификация пользователя
(которая может сопрягаться с защитой,
а может и не сопрягаться). В этом случае
от паролей отказаться невозможно, просто
потому, что не существует другой, столь
же эффективной, технологии идентификации.
При этом содержимое пароля как таковое
не очень важно, важно его отличие от
паролей других пользователей (обратите
внимание, что в этом случае само по себе
имя пользователя
является паролем).
Обычно в таких условиях при регистрации
применяют стандартную группу элементов
«имя, пароль, подтверждение пароля»,
после чего, уже при нормальной деятельности,
пользователь получает возможность
ввести пароль только в первый раз (см.
рис. 17).
Это неплохое решение, но и
оно не без недостатка. Дело в том, что
пользователь, однократно введя пароль,
потом его забывает, поскольку из-за
отсутствия повторения пароль никогда
не попадает в долговременную память. В
результате, когда пользователь переходит
на другой компьютер или переустанавливает
ОС, ему приходится регистрироваться
снова, что нехорошо. Во-первых, эта лишняя
работа раздражает. Во-вторых, база
пользователей при этом разбавляется
дубликатами, что всегда плохо сказывается
на стоимости этой базы. В-третьих, что
иногда самое главное, зарегистрировавшийся
во второй раз пользователь лишается
возможности получить уже использованное
им ранее имя, что огорчительно: например,
пользователь, забывший пароль от почтовой
службы, лишается как доступа к своему
почтовому ящику, так и возможность
получить прежний почтовый адрес. Конечно,
некоторые пользователи
воспользуются тем или иным способом
узнать свой прежний пароль, но отнюдь
не все.
Это значит, что помимо
какого-либо механизма напоминания
пользователям их потерянных паролей
(неважно какого, лишь бы заметного),
очень полезно не скрывать от пользователей
их пароль, т.е. выводить его в поле ввода
не звездочками, а открытым текстом. Это
решение хорошо ещё и тем, что количество
ошибочно набранных паролей здорово
сократится (тяжело набирать на клавиатуре
невидимое).
Таким образом, эффективнее
всего максимально здраво определить
степень важности защищаемой информации,
после чего выбрать адекватную схему
защиты, стараясь, чтобы она была
максимально лёгкой для пользователей.
Как правило, их субъективное удовлетворение
важнее потенциального вреда от потери
информации.
Самовыражение Страсть к
самовыражению является одной из самых
сильных черт человеческой натуры. В
большинстве случаев люди самовыражаются
через вещи (двигают мебель и покупают
модную одежду), когда нет вещей –
насвистывают или поют изящные песни
«лишенным приятности голосом». Ни один
человек не может существовать
сколько-нибудь продолжительное время
в обстановке, не допускающей самовыражения.
Среднестатистический человек проводит
в день около восемнадцати минут в
туалете, этого времени достаточно, чтобы
вызвать острое желание выразить себя:
покупается особая, не такая как у других,
вешалка для рулона туалетной бумаги,
стены красятся в сравнительно уникальные
цвета, а наиболее творческие «пользователи
туалета» вешают на дверь зеркало и т.д.
Неудивительно, что пользователи
хотят выразить себя и в программах,
которыми они пользуются. Соответственно,
возможность настроить систему под свои
нужды является мощной причиной
субъективного удовлетворения.
Проблема здесь в том, что
это очень дорого стоит. Времени на
самовыражение уходит крайне много.
Во-первых, пользователи не склонны
удовлетворяться первым получившимся
вариантом (творчество процесс
итерационный). Во-вторых, когда выходят
новые версии системы (или имеющаяся
версия разрушается от излишнего
самовыражения), все приходится начинать
сначала. По моим, очень грубым прикидкам,
на такой процесс самовыражения в среднем
уходит около 45 минут в неделю, если
согласиться с этим числом, получается,
что организация всего с сотней работников
теряет на этом еженедельно 75 часов, что
почти равняется потере недельной работы
двух человек.
С другой стороны, настроенный
под свои нужды интерфейс, судя по всему,
снижает усталость работников и повышает
их рабочее настроение.
В таких условиях потеря 45
минут в неделю может оказаться
скомпенсированной благодаря повышению
производительности труда. Таким образом,
в продуктах, продаваемых пользователям
напрямую, возможность настройки под
конкретного пользователя обязательна.
Во всех остальных случаях, судя по всему,
нужен способ настройки, позволяющий
максимально изменить вид системы
минимумом команд (чтобы снизить время,
затрачиваемое на самовыражение). Хорошим
вариантом является банальный выбор
варианта готовой настройки из списка
без возможности модифицировать встроенные
варианты.
Соседние файлы в папке Лекции по интерфейсам
- #
- #
- #
- #
- #
- #
- #
From Wikipedia, the free encyclopedia
(Redirected from Error Message)
An error message when attempting to use the Wikipedia Visual editor.
An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with graphical user interfaces, error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, to indicate that a desired operation has failed, or to relay important warnings (such as warning a computer user that they are almost out of hard disk space). Error messages are seen widely throughout computing, and are part of every operating system or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human–computer interaction.[1]
Common error messages[edit]
The following error messages are commonly seen by modern computer users:[citation needed]
- Access denied
- This error occurs if the user doesn’t have privileges to a file, or if it has been locked by some program or user.
- Device not ready
- This error most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving this disk.
- File not found
- The file concerned may have been damaged, moved, deleted, or a bug may have caused the error. Alternatively, the file simply might not exist, or the user has mistyped its name. This is most commonly seen on the internet with outdated links to web pages that no longer exist. On a local computer, this is more frequent on command line interfaces than on graphical user interfaces where files are presented iconically and users do not type file names.
- Low Disk Space
- This error occurs when the hard drive is (nearly) full. To fix this, the user should close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.
- Out of memory
- This error occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or install more memory.
- [program name] has stopped working.
- This message and similar ones are displayed by several operating systems when program causes a general protection fault or invalid page fault.
Notable error messages[edit]
- Abort, Retry, Fail? — A notoriously confusing error message seen in MS-DOS
An example of an Error message .vbs script
- Bad command or file name — Another notoriously common and confusing error message seen in MS-DOS
- The Blue Screen of Death — On Microsoft Windows and ReactOS operating systems, this screen appears when Windows or ReactOS can no longer run because of a severe error.[2] It is roughly analogous to a kernel panic on Linux, Unix, or macOS.
- Can’t extend — an error message from Acorn DFS. DFS stores files in non-fragmented contiguous disk space, this error is caused when trying to extend an open random-access file into space that is already occupied by another file.
- Guru Meditation — an error message from the Commodore Amiga, roughly analogous to a kernel panic or BSOD, also adopted by more recent products such as VirtualBox.
- HTTP 404 — A file not found error seen on the World Wide Web, usually resulting from a link to a page that has been moved or deleted, or a mistyped URL
- lp0 on fire — A Unix warning that the printer may be «on fire», literally or not
- Not a typewriter — A Unix error message that is confusing due to its now obsolete use of the word «typewriter», and which is sometimes output when the nature of the error is seemingly entirely different
- PC LOAD LETTER — An error on several HP laser printers that simply asked the user to add «Letter» size paper in a confusing way[3]
- SYNTAX ERROR — Seen on many computer systems when the received instructions are in a format they don’t understand
- HTTP 504 — An error found on the World Wide Web stating that a gateway timeout occurred in the internet link.
- Error 1603 — An error that states that a problem during installation of a computer program, this error particularly occurs on Windows computer systems.
- <application name> has stopped — An error message commonly found on Android devices, which states a current running application unexpectedly stops working or crashes.
- Success — one of the error messages (in this instance, POSIX) that occurs when the program has detected an error condition, yet the actual error message printing routine relies on C library to print the error reported by the operating system (in this case, errno.h), while the underlying system calls have succeeded and report no errors (in this case,
errno == 0). This is a form of sloppy error handling that is particularly confusing for the user. - [Connection Time Out Error Mac] — Error occurs on Mac systems when it takes more time to connect wireless networks.
Fail pets[edit]
Tumbeasts gnawing on servers, used by Tumblr in 2011
With the rise of Web 2.0 services such as Twitter, end-user facing error messages such as HTTP 404 and HTTP 500 started to be displayed with whimsical characters, termed Fail Pets or Error Mascots. The term «Fail Pet» was coined, or at least first used in print, by Mozilla Engineer Fred Wenzel in a post on his blog entitled «Why Wikipedia might need a fail-pet — and why Mozilla does not.»[4] Dr. Sean Rintel argues that error messages are a critical strategic moment in brand awareness and loyalty. Fail pets are of interest to marketers because they can result in brand recognition (especially through earned media). «However, that same recognition carries the danger of highlighting service failure.»[5] The most famous fail pet is Twitter’s Fail Whale (see Twitter service outages). Other fail pets include:
- Ars Technica: Moon Shark (March 3, 2013)
- FarmVille on Facebook: Sad cow.
- GitHub: Octocat
- Google: Broken robot (March 2, 2011)
- iCloud: Cloud with Apple System 7 emoticon-style face and a magnifying glass
- Macintosh: Sad Mac
- Palliser Furniture: Between the cushions (January 31, 2018)
- Tumblr: Tumbeasts (January 25, 2011)
- Twitter: Fail Whale / Twitter Robot (July 30, 2008)
- YouTube: Televisions (on main site), light static inside video window (embedded video)
- Cartoon Network: BMO [Asia]: Domo
- Google Chrome: T-Rex
- Patreon: Red fox with a helmet floating in space
- VK: Sad Vkontakte dog
- Scratch: Giga scratching his head
Message format[edit]
The form that error messages take varies between operating systems and programs.
Error messages on hardware devices, like computer peripherals, may take the form of dedicated lights indicating an error condition, a brief code that needs to be interpreted using a look-up sheet or a manual, or via a more detailed message on a display.
On computers, error messages may take the form of text printed to a console, or they may be presented as part of a graphical user interface. Error messages are often presented as a dialog box, which makes them cause a following mode error in the user interaction. In many cases the original error can be avoided by error prevention techniques. Instead of raising an error message the system design should have avoided the conditions that caused the error.[6]
While various graphical user interfaces have different conventions for displaying error messages, several techniques have become common:
- A dialog box, or pop-up message, appears in a window on the screen, blocking further interaction with the computer until it is acknowledged. On Mac OS X, sheets are a form of dialog box that are attached to a specific window.
- Notification icons appear to notify a user about a condition without interrupting their work. On Windows, notification icons appear in the System Tray. On Mac OS X, notification icons may appear in the menu bar, or may take the form of an application’s icon «bouncing» in the Dock. The GNOME user interface for Unix systems can display notification icons in a panel.
- Minor errors may be displayed in a status bar, a small portion of an application’s window that can display brief messages to the user.
The three main factors[7] that influence the design of error messages are technical limitations, the amount of information to be presented, and what kind of user input is required.
Some systems have technical limitations that may constrain the amount of information an error message can contain. For example, a printer with a sixteen-character alphanumeric display can only show a very limited amount of information at once, so it may need to display very terse error messages. Even with computer monitors, the programmer must consider the smallest monitor that a user might reasonably use, and ensure that any error messages will fit on that screen.
The nature of the error determines the amount of information required to effectively convey the error message. A complex issue may require a more detailed error message in order to adequately inform the user of the problem.
Security[edit]
When designing error messages, software designers should take care to avoid creating security vulnerabilities. The designer should give the user enough information to make an intelligent decision, but not so much information that the user is overwhelmed or confused. Extraneous information may be hidden by default or placed in a separate location. Error message should not expose information that can be exploited by a cracker to obtain information that is otherwise difficult to obtain. Examples are systems which may show either «invalid user» or «invalid password» depending on which is incorrect, and the error page in the web server IIS 5.0 which provides a complete technical description of the error including a source code fragment.
See also[edit]
- Alert dialog box
- Human–computer interaction
- Interaction design
- Usability
- User error
- User interface design
- Exception handling
References[edit]
- ^ Minhas, Saadis (May 30, 2018). «How to Write Good Error Messages». UX Planet. Retrieved Jan 30, 2019.
- ^ Fisher, Tim (2019-01-16). «Blue Screens of Death (BSOD): Everything You Need to Know». Lifewire. Retrieved 2019-01-30.
- ^ McNamara, Paul (2009-04-29). «LaserJet turns 25 … ‘PC LOAD LETTER’ still unfathomable». Network World. Retrieved 2019-01-30.
- ^ Wenzel, Fred. «why wikipedia might need a fail-pet — and why mozilla does not». Retrieved 8 February 2012.
- ^ Rintel, Sean (2 November 2011). «The Evolution of Fail Pets : Strategic Whimsy and Brand Awareness in Error Messages». UX Magazine. Retrieved 8 February 2012.
- ^ Raskin, Jef 2000.The Humane Interface, Addison-Wesley ISBN 0-201-37937-6. See chapter 6-4-2, Messages to the User
- ^ «Non-Fatal Errors: Creating usable, effective error messages». Retrieved 2007-02-16.
External links[edit]
- A more useful 404 (A List Apart)
- Avoid being embarrassed by your error messages (UX Matters)
- Oops! I ruined your life.
(Cooper Journal) Archived 2014-08-25 at the Wayback Machine
From Wikipedia, the free encyclopedia
(Redirected from Error Message)
An error message when attempting to use the Wikipedia Visual editor.
An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with graphical user interfaces, error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, to indicate that a desired operation has failed, or to relay important warnings (such as warning a computer user that they are almost out of hard disk space). Error messages are seen widely throughout computing, and are part of every operating system or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human–computer interaction.[1]
Common error messages[edit]
The following error messages are commonly seen by modern computer users:[citation needed]
- Access denied
- This error occurs if the user doesn’t have privileges to a file, or if it has been locked by some program or user.
- Device not ready
- This error most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving this disk.
- File not found
- The file concerned may have been damaged, moved, deleted, or a bug may have caused the error. Alternatively, the file simply might not exist, or the user has mistyped its name. This is most commonly seen on the internet with outdated links to web pages that no longer exist. On a local computer, this is more frequent on command line interfaces than on graphical user interfaces where files are presented iconically and users do not type file names.
- Low Disk Space
- This error occurs when the hard drive is (nearly) full. To fix this, the user should close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.
- Out of memory
- This error occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or install more memory.
- [program name] has stopped working.
- This message and similar ones are displayed by several operating systems when program causes a general protection fault or invalid page fault.
Notable error messages[edit]
- Abort, Retry, Fail? — A notoriously confusing error message seen in MS-DOS
An example of an Error message .vbs script
- Bad command or file name — Another notoriously common and confusing error message seen in MS-DOS
- The Blue Screen of Death — On Microsoft Windows and ReactOS operating systems, this screen appears when Windows or ReactOS can no longer run because of a severe error.[2] It is roughly analogous to a kernel panic on Linux, Unix, or macOS.
- Can’t extend — an error message from Acorn DFS. DFS stores files in non-fragmented contiguous disk space, this error is caused when trying to extend an open random-access file into space that is already occupied by another file.
- Guru Meditation — an error message from the Commodore Amiga, roughly analogous to a kernel panic or BSOD, also adopted by more recent products such as VirtualBox.
- HTTP 404 — A file not found error seen on the World Wide Web, usually resulting from a link to a page that has been moved or deleted, or a mistyped URL
- lp0 on fire — A Unix warning that the printer may be «on fire», literally or not
- Not a typewriter — A Unix error message that is confusing due to its now obsolete use of the word «typewriter», and which is sometimes output when the nature of the error is seemingly entirely different
- PC LOAD LETTER — An error on several HP laser printers that simply asked the user to add «Letter» size paper in a confusing way[3]
- SYNTAX ERROR — Seen on many computer systems when the received instructions are in a format they don’t understand
- HTTP 504 — An error found on the World Wide Web stating that a gateway timeout occurred in the internet link.
- Error 1603 — An error that states that a problem during installation of a computer program, this error particularly occurs on Windows computer systems.
- <application name> has stopped — An error message commonly found on Android devices, which states a current running application unexpectedly stops working or crashes.
- Success — one of the error messages (in this instance, POSIX) that occurs when the program has detected an error condition, yet the actual error message printing routine relies on C library to print the error reported by the operating system (in this case, errno.h), while the underlying system calls have succeeded and report no errors (in this case,
errno == 0). This is a form of sloppy error handling that is particularly confusing for the user. - [Connection Time Out Error Mac] — Error occurs on Mac systems when it takes more time to connect wireless networks.
Fail pets[edit]
Tumbeasts gnawing on servers, used by Tumblr in 2011
With the rise of Web 2.0 services such as Twitter, end-user facing error messages such as HTTP 404 and HTTP 500 started to be displayed with whimsical characters, termed Fail Pets or Error Mascots. The term «Fail Pet» was coined, or at least first used in print, by Mozilla Engineer Fred Wenzel in a post on his blog entitled «Why Wikipedia might need a fail-pet — and why Mozilla does not.»[4] Dr. Sean Rintel argues that error messages are a critical strategic moment in brand awareness and loyalty. Fail pets are of interest to marketers because they can result in brand recognition (especially through earned media). «However, that same recognition carries the danger of highlighting service failure.»[5] The most famous fail pet is Twitter’s Fail Whale (see Twitter service outages). Other fail pets include:
- Ars Technica: Moon Shark (March 3, 2013)
- FarmVille on Facebook: Sad cow.
- GitHub: Octocat
- Google: Broken robot (March 2, 2011)
- iCloud: Cloud with Apple System 7 emoticon-style face and a magnifying glass
- Macintosh: Sad Mac
- Palliser Furniture: Between the cushions (January 31, 2018)
- Tumblr: Tumbeasts (January 25, 2011)
- Twitter: Fail Whale / Twitter Robot (July 30, 2008)
- YouTube: Televisions (on main site), light static inside video window (embedded video)
- Cartoon Network: BMO [Asia]: Domo
- Google Chrome: T-Rex
- Patreon: Red fox with a helmet floating in space
- VK: Sad Vkontakte dog
- Scratch: Giga scratching his head
Message format[edit]
The form that error messages take varies between operating systems and programs.
Error messages on hardware devices, like computer peripherals, may take the form of dedicated lights indicating an error condition, a brief code that needs to be interpreted using a look-up sheet or a manual, or via a more detailed message on a display.
On computers, error messages may take the form of text printed to a console, or they may be presented as part of a graphical user interface. Error messages are often presented as a dialog box, which makes them cause a following mode error in the user interaction. In many cases the original error can be avoided by error prevention techniques. Instead of raising an error message the system design should have avoided the conditions that caused the error.[6]
While various graphical user interfaces have different conventions for displaying error messages, several techniques have become common:
- A dialog box, or pop-up message, appears in a window on the screen, blocking further interaction with the computer until it is acknowledged. On Mac OS X, sheets are a form of dialog box that are attached to a specific window.
- Notification icons appear to notify a user about a condition without interrupting their work. On Windows, notification icons appear in the System Tray. On Mac OS X, notification icons may appear in the menu bar, or may take the form of an application’s icon «bouncing» in the Dock. The GNOME user interface for Unix systems can display notification icons in a panel.
- Minor errors may be displayed in a status bar, a small portion of an application’s window that can display brief messages to the user.
The three main factors[7] that influence the design of error messages are technical limitations, the amount of information to be presented, and what kind of user input is required.
Some systems have technical limitations that may constrain the amount of information an error message can contain. For example, a printer with a sixteen-character alphanumeric display can only show a very limited amount of information at once, so it may need to display very terse error messages. Even with computer monitors, the programmer must consider the smallest monitor that a user might reasonably use, and ensure that any error messages will fit on that screen.
The nature of the error determines the amount of information required to effectively convey the error message. A complex issue may require a more detailed error message in order to adequately inform the user of the problem.
Security[edit]
When designing error messages, software designers should take care to avoid creating security vulnerabilities. The designer should give the user enough information to make an intelligent decision, but not so much information that the user is overwhelmed or confused. Extraneous information may be hidden by default or placed in a separate location. Error message should not expose information that can be exploited by a cracker to obtain information that is otherwise difficult to obtain. Examples are systems which may show either «invalid user» or «invalid password» depending on which is incorrect, and the error page in the web server IIS 5.0 which provides a complete technical description of the error including a source code fragment.
See also[edit]
- Alert dialog box
- Human–computer interaction
- Interaction design
- Usability
- User error
- User interface design
- Exception handling
References[edit]
- ^ Minhas, Saadis (May 30, 2018). «How to Write Good Error Messages». UX Planet. Retrieved Jan 30, 2019.
- ^ Fisher, Tim (2019-01-16). «Blue Screens of Death (BSOD): Everything You Need to Know». Lifewire. Retrieved 2019-01-30.
- ^ McNamara, Paul (2009-04-29). «LaserJet turns 25 … ‘PC LOAD LETTER’ still unfathomable». Network World. Retrieved 2019-01-30.
- ^ Wenzel, Fred. «why wikipedia might need a fail-pet — and why mozilla does not». Retrieved 8 February 2012.
- ^ Rintel, Sean (2 November 2011). «The Evolution of Fail Pets : Strategic Whimsy and Brand Awareness in Error Messages». UX Magazine. Retrieved 8 February 2012.
- ^ Raskin, Jef 2000.The Humane Interface, Addison-Wesley ISBN 0-201-37937-6. See chapter 6-4-2, Messages to the User
- ^ «Non-Fatal Errors: Creating usable, effective error messages». Retrieved 2007-02-16.
External links[edit]
- A more useful 404 (A List Apart)
- Avoid being embarrassed by your error messages (UX Matters)
- Oops! I ruined your life.
(Cooper Journal) Archived 2014-08-25 at the Wayback Machine
Автор: Майкл Болтон
Перевод: портал software-testing.ru
Оригинал статьи: http://www.developsense.com/essays/AReviewOfErrorMessages.html
Сообщение об ошибке, если его вывод вообще необходим, должно содержать полезную информацию как для пользователя, так и для техподдержки и разработчиков. Ниже предлагаются несколько пунктов, о которых стоит помнить при обработке ошибок и составлении сообщения об ошибках.
Начальные знания о сообщениях об ошибке
Программа выводит сообщение об ошибке в ответ на необычную или исключительную ситуацию, которую не может разрешить самостоятельно. Если программа написана корректно, сообщения об ошибке у нее выводятся нечасто: везде, где это возможно, программа сама справляется с возникающими проблемами и не обращается за помощью к пользователю.
С этой точки зрения можно выделить два класса плохо написанных программ. Во-первых, это программы, которые не могут самостоятельно исправить ошибку, либо требуют слишком много действий от пользователя. Во-вторых, программы, – и о них мы поговорим подробно, – которые при возникновении реальной проблемы выдают пользователю неадекватные сообщения об ошибке.
Конечно, самое лучшее сообщение об ошибке – это его отсутствие. Если что-то пошло не так, программа должна использовать все доступные средства, чтобы как можно быстрее исправить ошибку. Например, она не должна выводить сообщение о том, что файл не найден, если поиск не был произведен достаточно тщательно. Как минимум, разработчик должен предусмотреть возможность поиска файла на всех жестких дисках. Если файл был найден не в ожидаемом месте, программа должна либо обновить путь к файлу, либо создать копию файла в требуемом месте. В любом случае пользователя беспокоить не стоит.
Если вывести сообщение об ошибке все же необходимо, не тратьте время пользователя впустую, если можно заранее предсказать возникновение проблем. Например, программа установки не должна начинать копирование файлов, пока не произведена проверка на наличие свободного места на диске. Путём несложных вычислений можно определить, достаточно ли свободного места на диске, но большинство программ не делает такую проверку. Если программа установки прерывает процесс, когда ей требуется перезаписать какой-нибудь файл – это тоже плохо, так как вынуждает пользователя постоянно следить за процессом установки.
При этом не стоит полагаться и на операционную систему. Удивительно, но команды DOS COPY и XCOPY до сих пор не проводят проверку на наличие свободного места на диске перед началом копирования файлов; вместо этого копирование начинается “вслепую” с надеждой на то, что места будет достаточно. Windows ничуть не лучше, эта система тоже не проверяет диск на наличие свободного места перед копированием файлов. Хуже того, если вы одновременно копируете несколько файлов, Windows прерывает процесс копирования после обнаружения первой ошибки и “забывает”, какие файлы были выделены для копирования.
При написании программы старайтесь предугадать условия возникновения ошибки и реакцию системы на эти ошибки. Постарайтесь выполнить задачу пользователя максимально точно, и не относитесь к ошибке как катастрофе (если, конечно, это не является реальной катастрофой). Запомните состояние программы до возникновения проблемы и дайте пользователю возможность легко вернуться в это состояние. Всегда пишите функции, которые возвращают статус выполнения и используйте уникальный код ответа для каждой проблемной ситуации. Если возвращается код ответа, который свидетельствует о возникновении проблемы, обычно удаётся собрать достаточно информации, которую можно передать ответственным за исправление ошибки специалистам. С другой стороны, помните, что внутренние сбои в работе программы, с которыми она может справиться самостоятельно, не должны беспокоить пользователя, поэтому сообщения о таких ошибках не должны выводиться без крайней необходимости. Также в сообщении нужно четко разграничить информацию, предназначенную для пользователя, и необходимую для сотрудников техподдержки.
Как выглядит корректно составленное сообщение об ошибке?
Сообщение об ошибке должно:
- идентифицировать программу, которая его выводит;
- сообщать пользователю о конкретной проблеме;
- предлагать определенные способы решения этой проблемы;
- предоставлять информацию о том, куда пользователь может обратиться за помощью;
- предоставлять дополнительную информацию человеку, оказывающему помощь пользователю;
- предоставлять уникальный идентификационный код, который поможет отличить это сообщение от других, похожих на него.
Оно не должно:
- содержать информацию, которая не поможет в решении проблемы и на которую пользователь зря потратит время;
- содержать бесполезную, избыточную, неполную или неверную информацию.
Хороший пример
Одно из самых лучших сообщений об ошибке, которые я когда-либо видел, выглядело примерно так:
«Система ATS потеряла связь с принтером. Для решения проблемы убедитесь, что принтер включен, и попробуйте запустить печать снова. Если напечатать документ не удается, убедитесь, что оба конца кабеля, соединяющего компьютер с принтером, надежно соединены с устройствами, и попробуйте снова запустить печать. Если и в этом случае проблема не устранена, свяжитесь с Джо Грантом по номеру (212) 555-1212 и сообщите ему, что программа выдает ошибку ATSPR35 в строке 31, модуль PRNFNC»
Это сообщение программы по подбору персонала (называется «Система ATS»), созданной независимым разработчиком для кадрового агентства в 1988. Сообщение выглядит почти так, как я описал выше. Существенным отличием является то, что оно не имеет привычный вид окна Windows, потому что это сообщение из программы DOS. Я упоминаю об этом, потому что это сообщение было составлено во времена, когда объем памяти ограничивался 640 Кб. У пользователей тогда не было большого опыта работы с компьютером, но даже если бы они были экспертами в этой области, все равно сообщение было бы полезным.
Давайте сравним это сообщение с требованиями, предложенными выше:
- Сообщение совершенно четко идентифицирует программу. Более того, строка заголовка идентифицирует тип ошибки.
- В сообщении сказано о том, что программа потеряла связь с принтером. В сообщении не говорится «невозможно напечатать», или «LPT1: Ошибка», или любой другой малоинформативный текст, скопированный из операционной системы. Сообщения об ошибке большинства операционных систем очень лаконичны и обычно для пользователя бесполезны. А это сообщение составлено так, что его может понять обычный пользователь.
- В сообщении пользователю предлагаются действия, которые он способен выполнить, независимо от уровня или опыта владения программой. Здесь не высказываются догадки о причине ошибки. Предложенные действия располагаются от простого к более сложному, а причины – от более вероятных к менее вероятным. Отчасти здесь автору программы повезло – далеко не всегда самые распространенные ошибки проще всего исправить.
- Программа не предлагает действий, которые будут пустой тратой времени. («Попробуйте перезапустить программу», или еще хуже, «Попробуйте переустановить приложение».)
- Текст сообщения тщательно составлен. Важен каждый пункт сообщения. Нет бесполезных рекомендаций. Не предлагается искать причину сбоя в другом приложении. Вся информация точная и полезная.
- Самое главное, в сообщении есть полезная техническая информация и для пользователя, и для сотрудника техподдержки, и для разработчика. Если ошибка содержится в коде, сообщение указывает программисту, где именно следует искать ошибку и тип ошибки. Немаловажный плюс – указание реального имени человека. Приятнее иметь дело с конкретным человеком, чем с абстрактной организацией, наличие имени программиста говорит об ответственности за свою работу.
10 примеров неудачных сообщений об ошибке
Теперь для контраста приведу несколько примеров худших сообщений об ошибке. Все примеры взяты из программ Microsoft. Конечно это не единственная компания, которая разрабатывает программное обеспечение c невнятным пользовательским интерфейсом, но она, без сомнения, преуспела в искусстве создания особо раздражающих диалоговых окон, сообщающих об ошибке.
«Невозможно загрузить список новых групп. Произошла ошибка»
Да уж. Информация в сообщении совершенно очевидна и абсолютно бесполезна. Непонятно, что помогло бы в решении проблемы. Нет информации даже для техподдержки, которая могла бы помочь пользователю. Для программиста, ответственного за поддержку программы – а это обычно не тот человек, который писал исходный код – в данном сообщении нет даже намека на то, что вызвало ошибку, не говоря уже о коде ошибки вызванной функции. Если подобное сообщение выводится в результате разных ошибок, нет никакой возможности определить, какая из них произошла в данный момент.
К этому сообщению у меня вообще нет комментариев.
К этому тоже. Хотя оно выглядит не таким грозным как предыдущее.
«Интерфейс передачи сообщений вернул неизвестную ошибку. Если проблема повторяется, перезапустите Outlook»
Вам известно больше, чем вы сообщаете, и вы что-то скрываете? И кстати, как именно может помочь перезапуск Outlook?
«Переключение из режима Internet Only E-mail Service в режим Corporate or Workgroup E-mail Service может быть несовместимо с существующими приложениями»
Какими приложениями? В чём выражается несовместимость? Почему вы не устранили эту несовместимость? Ну, ещё повезло, что программа хотя бы не будет несовместима с несуществующими приложениями.
«Невозможно запустить программу. Возможно, один из компонентов занят или отсутствует. Пожалуйста, проверьте, правильность установки и попробуйте еще раз».
«Возможно». Компонент занят или отсутствует, или и то и другое? Если компонент используется, то какой именно компонент? Файл? Если так, можно узнать имя файла?
«Действие не может быть выполнено. Действие не может быть выполнено».
Правда? Правда? Какое действие? Какое действие? Что я должен сделать, чтобы устранить проблему? Что я должен сделать, чтобы устранить проблему?
«Невозможно найти файл cuecard.hlp. Хотите найти файл вручную?»
Нет, не хочу. Я хочу, чтобы вы его нашли.
«Невозможно найти файл cuecard.hlp. Проверьте наличие файла на вашем диске. Если файл не будет найден, переустановите его».
Может, все-таки поищете, нет? Честно говоря, я не помню ситуацию, при которой я получил это сообщение, соответственно не помню и программу, которая его вывела. Тем не менее, я помню, что и тогда мне было непонятно, что мне следует переустановить.
Почему сообщения об ошибках обычно составлены некорректно, и как это можно исправить?
В обучающих материалах по программированию редко говорят о сообщениях об ошибках или обработке ошибок. В каких книгах рассказывается о важности проверки кодов возврата операционной системы или библиотечных функций и корректной обработке ошибок? Много ли существует примеров кода с хотя бы минимальной проверкой на ошибки? Часто ли в книгах рассматриваются такие основополагающие вопросы разработки пользовательского интерфейса, как создание сообщений об ошибках?
Обычно сообщения об ошибках совершенно бесполезны, потому что их пишут люди, которые знают программу во всех деталях. Они не думают о том, что программой будут пользоваться люди, которые такими знаниями не обладают. Поэтому очень важно при написании сообщений помнить о конечном пользователе; о том, что программой будут пользоваться другие люди; о том, что каждое сообщение об ошибке программист составляет не только для себя. Пользователь не обязан знать программу во всех деталях. Предоставляемая информация должна быть подробной и понятной. Сообщение не должно ставить пользователя в тупик.
Программу нужно писать так, чтобы сообщения об ошибках появлялись как можно реже. Чтобы облегчить идентификацию ошибок, включите в вашу программу функцию протоколирования или режим подробной диагностики. Все функции программы, которые могут дать сбой, должны иметь код ошибки, который должен отображаться в сообщении об ошибке. Такие коды помогают выявить причину ошибки, а также облегчают тестирование локализованных версий. Документируйте эти коды ошибок, и в сообщение включите информацию о том, где находится эта документация, чтобы помочь техподдержке. Убедитесь, что в программе есть механизм для идентификации отсутствующих файлов, записей реестра и т. д. Создайте классы и функции обработки ошибок, чтобы получить систематизированные, корректно оформленные сообщения об ошибках – и постоянно используйте их в своей работе в дальнейшем. Проведите анализ кода, проверьте программу с другими разработчиками, чтобы убедиться, что программу легко читать и поддерживать, что в ней нет дефектов и она логически последовательна. Предоставьте тестировщикам инструменты для тестирования или программу, которая позволит просмотреть все сообщения об ошибках в вашей программе.
Прототипирование – полезная стратегия для работы с сообщениями об ошибках. Во время разработки программы создайте скелет для каждой функции. Пока вы не наполнили функции содержимым, оставьте все как есть и возвращайте положительный код возврата. Определите коды возвратов как символы – константы или значения перечислимого типа. Позже, когда вы будете наполнять функции (и когда будете проверять коды возврата на каждом этапе), определите отдельные коды для каждого типа ошибок.
Программировать сейчас, конечно, сложнее, чем раньше. С каждым днем нужно осваивать все больше новых технологий, языков программирования, различных смежных дисциплин. От разработчиков требуют писать код быстрее, это оставляет меньше времени для размышлений о дизайне. Однако программистам и менеджерам не стоит обманываться – никто в компании не захочет взять на себя ответственность за дефекты и ошибки в программе, уже переданной на тестирование (или, хуже того, пользователю). Поэтому разработчики и менеджеры должны в своем рабочем плане выделить время на проектирование и на отладку, при необходимости закладывать больше времени и предусмотреть дополнительную помощь, особенно в вопросах, не требующих программирования, например, таких как разработка интерфейса пользователя.
Представьте себя на месте пользователя, который столкнулся с проблемой – вряд ли техподдержка отреагирует немедленно. Когда вы составляете сообщение об ошибке, важно помнить, что содержащаяся в нём информация должна быть полезной. Полезная информация экономит время. Помните также о том, что сообщение будут читать не только пользователи. Сообщение должно быть полезным и для сотрудников техподдержки, которые принимают звонки от пользователей, и для сотрудников контроля качества, которые помогают в поиске причины сбоя, и для программиста, ответственного за исправление ошибки в коде. Каждый специалист в этом процессе – это расход для компании. И если код обработки ошибок можно написать только один раз, то поддержку нужно будет оказывать многократно – десятки, сотни, или даже тысячи раз. Сотрудничайте с техподдержкой, тестировщиками и авторами технической документации; задавайте вопросы, считайте расходы и пытайтесь оценить стоимость решения проблем, возникающих после выпуска продукта. Не забудьте учесть в своих расчетах снижение продаж. Если руководство вашей компании хочет быстрее выпустить продукт на рынок и отказывается выделить время на обработку ошибок, вежливо напомните о том, во сколько может обойтись такая политика.
Обсудить в форуме
Любая система допускает ошибки. Это может быть как человеческий фактор, так и ошибка самой системы. В обоих случаях, нужно правильно эти ошибки отображать, так как они являются очень важным элементом пользовательского опыта.
Вот 3 жизненно важных части любого хорошего сообщения об ошибке:
- Четкое текстовое сообщение
- Правильное размещение
- Хороший визуальный дизайн
Четкое текстовое сообщение
1. Сообщение об ошибке должно быть понятным
Сообщение об ошибке должно четко говорить о том, какая именно ошибка произошла, почему она произошла, и что с этим делать. Думайте об этом сообщении, как об общении с пользователем — оно должно звучать так, будто оно написано для человека, а не для машины. Убедитесь, что ваше сообщение вежливо, понятно, дружественно, и не содержит жаргона.
2. Сообщение об ошибке должно быть полезным
Не достаточно просто написать, что что-то пошло не так. Покажите пользователю, как он может исправить проблему.
Например, Microsoft описывает проблему, и прямо в сообщении об ошибке предоставляет вариант ее решения.
3. Сообщение об ошибке должно подходить под определенную ситуацию
Очень часто, веб-сайты используют одно сообщение об ошибке для всех схожих состояний. Оставили пустым поле ввода электронного адреса — «Введите правильный электронный адрес», пропустили символ «@» — «Введите правильный электронный адрес». MailChimp решает эту проблему иначе — они используют 3 разных сообщения об ошибке для каждого состояния процесса подтверждения электронной почты. Сначала проверяется, заполнено ли поле ввода. Затем проверяется введены ли символы «@», и «.».
4. Сообщение об ошибке должно быть вежливым
Не вините пользователей в том, что они что-то не так сделали, даже если это так. Будьте вежливы, дайте им почувствовать себя комфортно.
5. Используйте юмор, если он уместен
Но будьте осторожны. Сообщение об ошибке, в первую очередь, должно быть информативным и полезным. И уже затем, можете улучшить пользовательский опыт, добавив немного юмора, но только если он уместен.
Правильное размещение
Хорошее сообщение об ошибке — это такое сообщение, которое вы увидите. Размещайте его рядом с элементами интерфейса, с которыми ошибка непосредственно связана.
Правильный визуальный дизайн
Сообщение об ошибке должно быть заметным. Используйте контрастный текст и фоновые цвета, чтобы пользователь мог легко его рассмотреть и прочесть.
Обычно, используется красный цвет. В некоторых случаях желтый или оранжевый (некоторые ресурсы утверждают, что красный цвет нервирует пользователей). Как бы то ни было, убедитесь, что ваш текст разборчив, и хорошо контрастирует с фоном. Не забудьте внедрить в сообщение связанную с ним иконку — это улучшит доступность сообщения для людей с нарушенным восприятием цветов.
Заключение
Сообщения об ошибках — это отличный способ улучшить пользовательский опыт. Чтобы ваше сообщение стало действительно идеальным, уделите внимание всем аспектам — языку, размещению, и визуальному дизайну.
Предыдущая статья
F-паттерн: как пользователи просматривают контент
Следующая статья
Метрики, за которыми должен следить любой SEO аналитик
Каким должно быть сообщение об ошибке
Теперь можно рассказать,
каким должно быть сообщение об ошибке,
тем более, что ничего сложного в создании
идеального сообщения нет. Напротив, всё
очень просто. Идеальное сообщение об
ошибке должно отвечать всего на три
вопроса:
— В чем
заключается проблема?
— Как исправить
эту проблему сейчас?
— Как сделать
так, чтобы проблема не повторилась?
При этом отвечать на эти
вопросы нужно возможно более вежливым
и понятным пользователям языком. В
качестве примера идеального сообщения
об ошибке удобно взять какое-либо
существующее сообщение (из тех, которые
точно нельзя просто изъять из системы)
и попытаться это сообщение улучшить.
Например, попытаемся улучшить уже
упоминавшееся в предыдущей главе
сообщение о невозможности перезаписать
заблокированный файл.
Итак, старое сообщение об
ошибке гласило: «Не удается сохранить
файл «D:Только для чтения.doc». Файл с
этим именем уже существует и доступен
только для чтения. Сохраните файл под
другим именем или в другой папке». Это
довольно неплохое сообщение, во всяком
случае, оно гораздо лучше, чем «Указано
неверное число». Но и его можно улучшить.
Сначала надо разобраться, в каких случаях
оно появляется. Это несложно: оно может
появляться, если пользователь попытался
сохранить файл на компакт-диске, или же
пытается сохранить файл, незадолго
перед этим скопировав этот файл с
компакт-диска. Случаи, когда файл
заблокирован сознательно, в жизни редки,
так что их чаще всего можно не учитывать.
Главный враг – компакт-диск.
Тут возможно несколько
непротиворечащих друг другу решений.
Во-первых, просто можно блокировать
возможность что-либо записать на диске,
запись на который невозможна. Собственно
говоря, запись и так блокируется, но
сообщением об ошибке. А можно просто не
показывать диски, на которые нельзя
записывать, в окне записи, что эффективнее,
поскольку делает ошибку невозможной.
Во-вторых, как уже говорилось, можно
показывать файлы, защищенные от записи,
иначе, чем файлы незащищенные. Это будет
работать, но тоже неидеально. Что делать
пользователю, который всё-таки хочет
перезаписать файл? Сейчас в такой
ситуации приходится записывать файл
под новым именем, потом стирать старый,
а новому давать имя старого. Это и потери
времени и ошибочно стертые файлы (лучший
способ сделать так, чтобы пользователи
не стирали нужные файлы, заключается в
том, чтобы лишить пользователей
необходимости вообще что-либо стирать
в нормальном режиме работы).
Таким образом, сообщение
об ошибке должно стать не только
сообщением – оно должно позволять
разблокировать файлы, разблокировать
которые возможно (т.е. записанные не на
компакт-диске). Таким образом, получается,
что нужно сделать несколько изменений
в интерфейсе:
— Диски, на
которые ничего нельзя записать, не
показываются в диалоговом окне сохранения
файлов.
— Заблокированные
файлы на остальных дисках показываются
иначе, нежели файлы незаблокированные.
— При попытке
записать документ поверх заблокированного,
появляется сообщение об ошибке примерно
такого вида:
Рис. 15. Улучшенное сообщение
об ошибке. Обратите внимание, что кнопка
Закрыть выбрана
по умолчанию, чтобы снизить вероятность
перезаписи важных файлов. Конечно, лучше
всего было бы, чтобы ОС сама снимала с
копируемых с компакт-диска файлов метку
Read Only. Многие проблемы при этом бы
исчезли, поскольку защищенными от записи
остались только действительно важные
для ОС файлы.
Про этот пример осталось
сказать немного. Во-первых, никогда не
забывайте показывать текст сообщений
об ошибке техническому писателю.
Во-вторых, всемерно старайтесь делать
текст сообщения возможно более коротким.
В-третьих, диалоговое окно не самый
лучший способ показывать сообщения об
ошибках, во всяком случае, в ПО. Дело в
том, что в Windows появился элемент управления,
значительно лучше предназначенный для
показа сообщений. Называется этот
элемент весьма поэтично: пузырь
Рис. 16. Пузырь в его лучшем
проявлении (не обращайте внимания на
текст).
Пузырь, по сравнению с
диалоговым окном, имеет существенные
достоинства. Во-первых, он гораздо слабее
сбивает фокус внимания, нежели окно.
Во-вторых, чтобы закрыть пузырь,
пользователям не обязательно нажимать
на какую-либо кнопку, достаточно щелкнуть
мышью в любом месте экрана. В-третьих,
он не перекрывает значимую область
системы. В-четвертых, что самое главное,
он показывает, в каком именно элементе
управления была допущена ошибка. Все
это делает пузырь вещью совершенно
незаменимой. Я уверен, что через пару
лет 80 процентов всех сообщений об ошибках
будет появляться в пузырях.
К сожалению, пузыри имеют
и недостатки. Во-первых, в них не может
быть никаких элементов управления, так
что использовать пузырь в предыдущем
примере, например, было невозможно. В
Windows пузыри вообще реализованы довольно
бедно. Во-вторых, пузырей вообще нет в
интернете. Так что правило тут простое
–используйте пузыри всегда, когда это
возможно, и рыдайте, когда их нет.
Пароли.
Не только пароли, но сама по себе идея
секретности вызывает у пользователей
изжогу. Причем, что нечасто случается,
изжогу пароли вызывают не только у
какой-то отдельной группы пользователей,
такой как новички, а у всех. Объясняется
это просто – соблюдение секретности
требует от пользователей выполнения
действий, не приносящих пользы, но
уменьшающих потенциальный
вред. Человеческая
же природа такова, что потенциальное
кажется неважным, а вот действия, которые
приходится совершать, важны чрезвычайно.
В результате пароли не любит никто.
Разумеется, это не совсем
интерфейсная проблема, скорее политическая,
но она оказывает такое влияние на
результат, что обойти её невозможно.
Итак, пароли. Они имеют три принципиальных
проблемы. Во-первых, как уже было сказано,
пользователи не любят их вводить.
Во-вторых, пользователи либо забывают
пароли, либо пароли не работают, т.е.
ничего не защищают, поскольку пользователи
используют те пароли, которые они помнят
и которые, соответственно, непроблематично
подобрать. В-третьих, в интернете часто
происходит так, что пользователи, не
желая вводить пароль (и регистрироваться,
к слову говоря) так никогда не попадают
в главную часть сайта. В результате,
пароли есть явное и несомненное зло,
вопрос состоит лишь в том, как это зло
уменьшить.
Для этого есть несколько
путей. Во-первых, от них можно отказаться
вообще. Этот путь почти всегда
предпочтителен, проблема в том, что он
вызывает существенное отторжение у
сетевых администраторов (которые все
как один параноики). В самом деле, зачем
требовать от пользователя пароль, если
подобрать этот пароль злоумышленник
сможет без труда?
И обратно: поскольку
единственным способом создания
действительно трудноподбираемых паролей
является генератор случайных чисел,
каковые числа (символы, по необходимости)
невозможно запомнить, пользователи
либо будут записывать их на бумажке (в
этом случае пароли еще легче украсть),
либо будут забывать, что дорого стоит.
Я, например, вынужден пользоваться
четырьмя действительно случайными
паролями, причем тремя из них не реже
раза в неделю. При этом, несмотря на то,
что я пользуюсь этими паролями не менее
года, я не помню ни
одного. В результате,
все четыре пароля записаны у меня на
бумажке, которую увидеть может любой
(я её не прячу). Какая уж тут защита?
Рис. 17. Стандартный способ
человеколюбивого использования паролей:
слева во время регистрации, справа в
дальнейшей работе.
Этот метод хорош, когда дело
касается защиты информации. Однако
гораздо чаще, особенно в интернете,
важна не столько защита информации,
сколько идентификация пользователя
(которая может сопрягаться с защитой,
а может и не сопрягаться). В этом случае
от паролей отказаться невозможно, просто
потому, что не существует другой, столь
же эффективной, технологии идентификации.
При этом содержимое пароля как таковое
не очень важно, важно его отличие от
паролей других пользователей (обратите
внимание, что в этом случае само по себе
имя пользователя
является паролем).
Обычно в таких условиях при регистрации
применяют стандартную группу элементов
«имя, пароль, подтверждение пароля»,
после чего, уже при нормальной деятельности,
пользователь получает возможность
ввести пароль только в первый раз (см.
рис. 17).
Это неплохое решение, но и
оно не без недостатка. Дело в том, что
пользователь, однократно введя пароль,
потом его забывает, поскольку из-за
отсутствия повторения пароль никогда
не попадает в долговременную память. В
результате, когда пользователь переходит
на другой компьютер или переустанавливает
ОС, ему приходится регистрироваться
снова, что нехорошо. Во-первых, эта лишняя
работа раздражает. Во-вторых, база
пользователей при этом разбавляется
дубликатами, что всегда плохо сказывается
на стоимости этой базы. В-третьих, что
иногда самое главное, зарегистрировавшийся
во второй раз пользователь лишается
возможности получить уже использованное
им ранее имя, что огорчительно: например,
пользователь, забывший пароль от почтовой
службы, лишается как доступа к своему
почтовому ящику, так и возможность
получить прежний почтовый адрес. Конечно,
некоторые пользователи
воспользуются тем или иным способом
узнать свой прежний пароль, но отнюдь
не все.
Это значит, что помимо
какого-либо механизма напоминания
пользователям их потерянных паролей
(неважно какого, лишь бы заметного),
очень полезно не скрывать от пользователей
их пароль, т.е. выводить его в поле ввода
не звездочками, а открытым текстом. Это
решение хорошо ещё и тем, что количество
ошибочно набранных паролей здорово
сократится (тяжело набирать на клавиатуре
невидимое).
Таким образом, эффективнее
всего максимально здраво определить
степень важности защищаемой информации,
после чего выбрать адекватную схему
защиты, стараясь, чтобы она была
максимально лёгкой для пользователей.
Как правило, их субъективное удовлетворение
важнее потенциального вреда от потери
информации.
Самовыражение Страсть к
самовыражению является одной из самых
сильных черт человеческой натуры. В
большинстве случаев люди самовыражаются
через вещи (двигают мебель и покупают
модную одежду), когда нет вещей –
насвистывают или поют изящные песни
«лишенным приятности голосом». Ни один
человек не может существовать
сколько-нибудь продолжительное время
в обстановке, не допускающей самовыражения.
Среднестатистический человек проводит
в день около восемнадцати минут в
туалете, этого времени достаточно, чтобы
вызвать острое желание выразить себя:
покупается особая, не такая как у других,
вешалка для рулона туалетной бумаги,
стены красятся в сравнительно уникальные
цвета, а наиболее творческие «пользователи
туалета» вешают на дверь зеркало и т.д.
Неудивительно, что пользователи
хотят выразить себя и в программах,
которыми они пользуются. Соответственно,
возможность настроить систему под свои
нужды является мощной причиной
субъективного удовлетворения.
Проблема здесь в том, что
это очень дорого стоит. Времени на
самовыражение уходит крайне много.
Во-первых, пользователи не склонны
удовлетворяться первым получившимся
вариантом (творчество процесс
итерационный). Во-вторых, когда выходят
новые версии системы (или имеющаяся
версия разрушается от излишнего
самовыражения), все приходится начинать
сначала. По моим, очень грубым прикидкам,
на такой процесс самовыражения в среднем
уходит около 45 минут в неделю, если
согласиться с этим числом, получается,
что организация всего с сотней работников
теряет на этом еженедельно 75 часов, что
почти равняется потере недельной работы
двух человек.
С другой стороны, настроенный
под свои нужды интерфейс, судя по всему,
снижает усталость работников и повышает
их рабочее настроение.
В таких условиях потеря 45
минут в неделю может оказаться
скомпенсированной благодаря повышению
производительности труда. Таким образом,
в продуктах, продаваемых пользователям
напрямую, возможность настройки под
конкретного пользователя обязательна.
Во всех остальных случаях, судя по всему,
нужен способ настройки, позволяющий
максимально изменить вид системы
минимумом команд (чтобы снизить время,
затрачиваемое на самовыражение). Хорошим
вариантом является банальный выбор
варианта готовой настройки из списка
без возможности модифицировать встроенные
варианты.
Соседние файлы в папке Лекции по интерфейсам
- #
- #
- #
- #
- #
- #
- #