Работа над ошибками

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

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

Благодаря подобной подаче информации, можно простить за это досадное недоразумение и MySQL, и colourlovers.com.

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

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

Широко распространено мнение о том, что такие страницы стоит использовать как рекламную площадку, но на мой взгляд это плохая практика и показатель хамоватости администрации сайта («404 — Этой страницы у нас нет, но мы может предложить вам пылесос!»). Если речь идет о веб-магазине, лучше просто прозрачно редиректить заблудших посетителей на главную страницу сайта.

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

«Без окон, без дверей, пейдж дазнотэкзыст!»

Примером его прямой противоположности может быть ошибка 404 на Яндексе:

Еще один запоминающийся вариант с сообщением об отсутсвующей странице в виде правильно-сложенного хайку:

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

Наличие подобных сообщений — показатель небрежности и потенциальный источник опасности, т.к. в них выдается на всеобщее обозрение внутренняя техническая информация о работе CMS, которую никогда не стоит распространять без явной на то необходимости. Тем более, что в том же PHP (а так же Перле, Руби, Джаве и большинстве других языков, на которых пишутся CMS) не представляет никакой сложности запретить выдачу трейсов ошибок в веб, и, при необходимости, перенаправлять их в логи.

Further reading:

• Подборка из нескольких десятков скриншотов хороших примеров страниц 404-й ошибки на smashingmagazine.com.
• Error Message Guidelines by Jakob Nielsen
• Improving the Dreaded 404 Error Message by Jakob Nielsen
• 404 Research Lab
• User friendly 404 error messages reconsidered by Jesper Tverskov

Комментарии к заметке «Работа над ошибками»

# Kupuyc: ^{(17 декабря, 2007 @ 16:11)}

Любопытно, спасибо.

# larin: ^{(18 декабря, 2007 @ 00:34)}

Согласен, о мелочах не стоит забывать ))) Как же мне понравилась идея с MySQL ошибкой!!!! Надо будет перенять )

# admin: ^{(18 декабря, 2007 @ 00:37)}

larin: Да, меня тоже улыбнуло, когда увидел (:

# Paradigm.ru » Blog Archive » Обработка сообщений об ошибках PHP: ^{(9 января, 2008 @ 16:10)}

[...] «Работа над ошибками» я уже упоминал о том, насколько неуместно [...]

# Plaza: ^{(11 августа, 2008 @ 16:29)}

Полезная статья. Спасибо)

Написать комментарий