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

Правила написания сообщений об ошибках

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

Правила создания продуктивных сообщений об ошибках не меняются вот уже 20 лет. Прекрасное сообщение об ошибке должно:

откровенно указывать, что что-то не так. Самое плохое сообщение об ошибке это то, которое не создали. Если пользователи выполняют погрешность и не получают никакого отклика от системы, это самое худшее для них. К примеру, приложение работы с электронной почтой имеет пару обстоятельств, где указание о случившейся ошибке было бы откровенно полезным. Скажем, вы отправили почтовое сообщение, какое было успешно проглочено системой, но так и не достигло адресата. Еще пример? Вы сообщаете в письме, что прилагаете к нему файл, но просто забыли сделать это. Вот тут-то и нашлась бы работа для такой глупой скрепки из MS Office: «Похоже, вы хотели закрепить файл к вашему сообщению, однако не выполнили этого. Желаете сделать это?».
Быть написано на человеческом языке, а не с применением таинственных кодов и сокращений типа » случилась ошибка типа 2?.
Быть вежливым и не оговаривать пользователей в том, что они такие глупые или выполнили что-то не так, как к примеру в сообщении «запрещенная команда».
Точно описывать источник проблемы, а не просто выдавать общие фразы типа » синтаксическая ошибка».
Давать конструктивный совет про то, как поправить проблематику. К примеру, взамен того, чтобы сообщать про то, что товара » нет в наличии», ваше сообщение об ошибке должно либо сообщать, когда товар будет в наличии, или предлагать пользователям настроить отсылку им сообщения-уведомления, когда товар возникнет в наличии.

Очень популярная ошибка в Web — 404 — нарушает большинство из данных правил. Я советую вам написать собственное свое сообщение об ошибке 404 взамен того, чтобы надеяться на скупую серверную фразу «page not found».

Новые правила

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

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

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

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

Вот еще пару правил, которые дадут возможность ослабить малоприятную ситуацию, в которую попадает пользователь при ошибке:

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

Обучение пользователей

И в конце концов, вы наверняка уже знаетеПервый Закон Нильсена о компьютерной документации: люди ее не читают. Этот закон действует еще сильнее для интернет ресурсов, где пользователи на самом деле избегают читать то, что не значительно для их задачи. Щелкнуть по ссылке «Помощь»? Да ни за что.

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

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