Путеводитель: Часть 1. Вступление ● Часть 2. Речевой барьер ● Часть 3. Ошибки в формах ● Часть 4. Ошибки на сервере ● Часть 5. Рука помощи
В предыдущей статье мы выяснили, что сайт без ошибок — это утопия,— а также, что ошибки необходимо показывать в доступной для пользователя форме. В первой части речь шла в основном о визуальном представлении ошибок: их расположении, выделении и стилизации. Это была своего рода обложка книги и мы ещё будем обсуждать её в дальнейшем, но сейчас пришло время поговорить о содержимом.
Я думаю, способа показать ошибку графически (без применения слов), кроме как заставить пользователя разгадывать ребусы, не существует. Иконка или какая-нибудь другая графика (в большинстве случаев, красного цвета) лишь показывает, что это действительно ошибка и способствует «остановки глаза». По сему, всегда существует вторая часть ошибки — текст (или речь). Текстовое содержимое ошибки, как правило, пишется справа от иконки и представляет собой пояснение возникшей проблемы. Вроде бы всё понятно: есть иконка, есть текст; иконка привлекает внимание, текст поясняет, что именно произошло. Однако, очень большое количество отечественных и зарубежных веб-разработчиков не принимают это во внимание.
Я сравниваю текст ошибки с речью, ведь имеет место общение пользователя с интерфейсом сайта. Именно последний должен рассказать пользователю, что произошло, и почему тот увидел красный кружок с крестиком. Время, когда с машинами общались лишь узконаправленные специалисты, давно прошло: сейчас в интернете можно встретить как амбициозного подростка, так и пожилого пенсионера — оба они хотят получить определённую информацию. В силу этого необходимо «дрессировать» интерфейс и учить его разговаривать на человеческом языке, а не на языке MySQL-запросов, PHP или Perl, при всём моём к ним уважении.
Для того, чтобы прояснить ситуацию, введём понятие ясности ошибки. Ясность ошибки — это свойство текстовой части ошибки, показывающее насколько хорошо пояснена возникшая проблема. Ясность ошибки складывается из многих критериев, которые мы рассмотрим ниже. Хочу предупредить, что мы будем рассматривать только текстовую часть ошибки, поэтому прошу строго не судить визуал.
Первое и главное: наличие текстовой части ошибки (http://viewlink.ru)
На развлекательном портале viewlink.ru я попытался открыть страницу, доступную только для зарегистрированных пользователей. Всё хорошо. Я увидел и иконку, что привлекло мой взгляд, и пояснение. Оставлять одну иконку не допустимо.
Язык ошибки и интерфейса должен быть одинаковым (http://ru.wikipedia.org/)
404 ошибка в русской версии википедии написана на английском. Я россиянин, я зашел на русскую версию сайта. Почему я должен видеть ошибку на английском? Да, я знаю, что сервис многоязычный, что для него выделен один домен второго уровня и что легче использовать одну ошибку на все версии, но это не должно волновать пользователей. Например, на lastfm.ru с этим всё нормально.
Текст ошибки не должен быть рассчитан только на разработчика (http://moikrug.ru/)
Известная ошибка на сайте Мой Круг. Меня не волнует, где в запросе к базе стоит лишняя точка, что не найдена таблица «site.names», потому что её удалил злобный хакер и что компилятор обнаружил ошибку в строке 7 — это всё для разработчиков. Мне важно знать, смогу ли я использовать сайт сейчас, а если нет, то когда. Обычно «ошибки для разработчика» возникают на сайтах, где используют бесплатные движки, но, опять же, цена движка пользователя не волнует.
Вообще, стоит избегать стандартных ошибок компилятора или базы данных (типа: «Critical error: couldn’t connect to database»). Также не стоит злоупотреблять специфическими компьютерными терминами. Конечно, использовать такие слова, как база данных и сервер можно, потому что без них просто не обойтись; так же допустимо использовать специфические термины в ошибках на специфических сайтах (например, для людей с какой-нибудь IT-профессией), но вот писать: «Неверное значение текстовой переменной names» — или что-то в этом духе — недопустимо.
Примеры хороших ошибок: «Извините, на сайте произошел сбой. Мы уже ведем работу по его устранению. Скорее всего сайт будет доступен завтра», «Извините, на сайте произошла ошибка базы данных. Мы уже её устраняем. Зайдите позже», «Приносим извинения, но сейчас сайт перегружен из-за большого количества пользователей. Зайдите позже». Ошибки с базами данных, произошедшие по вине пользователя допускаться вообще не должны.
Формулировка ошибки должна быть привычной, ясной и четкой (http://agava.ru)
В ошибках необходимо использовать правильную и привычную последовательность слов, а также избегать литературных оборотов: ошибка не сочинение. Клише выглядит примерно так: «%объект% + %что_делает% + %признак_предмета_действия% + %предмет_действия%». Здесь играет свою роль рефлекс (привычка, если хотите), поэтому, если вы мастер Йода, то, пожалуйста, воздержитесь от: «Ошибка произошла. Неверный домен формат имеет» — вашей уникальной манеры речи.
Где-то в блогах я видел сайт, на котором ошибка, известная всем, как: «Вы не ввели логин»,— отображалась просто: «Ммм…». Если сайт рассчитан на продвинутых воинов УП4К, Онотолеей, Девидов Блейнов и других любителей интернет-сленга, то такие шутки допустимы. Надо ли говорить, что на остальных сайтах этого делать нельзя? Я думаю, нет.
Выводы:
— всегда писать текстовую часть ошибки;
— писать ошибку только на языке интерфейса сайта;
— избегать ошибок сервера и ошибок компилятора, а также других ошибок для разработчика;
— формулировать ошибку четко, не используя литературных оборотов и неправильных словесных последовательностей;
— аккуратно относиться к компьютерным терминам при написании текста ошибки;
— обязательно приносить извинения пользователю за ошибку, если она произошла не по его вине;
— если ошибка произошла не по вине пользователя, указывать приблизительное время её исправления.
Соблюдая эти правила мы сможем добиться большой ясности ошибки.
Оригинал статьи можно найти в моём жж.
Роман Горшков (gorshkof)
