Одной из важнейших составляющих удобного интерфейса любого сложного приложения являются сообщения пользователю. Среди них -- сообщения об ошибках. И к сожалению именно они часто оказываются не понятными.
Часто разработчики оставляют сообщения об ошибках в виде понятном только им самим. Видимо в надежде, что пользователь никогда их не увидит.
Особенно ужасны сообщения об ошибках вроде: "ошибка №XXXX".
В целом помимо просто непонятных сообщений об ошибках существует по-меньшей мере два примера типичных методов обработки ошибок, которые не дают достаточной информации о ней:
Если существует три условия a, b и c, которые должны выполнятся одновременно существует большой соблазн использовать следующий код обработки:
if ( ! (a && b && c) )
{
/*Ошибка*/
...
}Объединяя три различных варианта ошибки в один. В результате пользователь не сможет узнать по сообщению об ошибке, что именно не так. И если он не разработчик и не может добавлять дополнительные проверки при необходимости, то единственная возможность уточнить, это выбрать исходные данные так, чтобы проверить все три возможных варианта.
Если функция a() вызывает функцию b(), в которой происходит ошибка, то часто сообщение об ошибке пишется только в одной из этих функций. В любом случае при этом возникает не полнота сообщения об ошибке. Например, "При открытии документа произошла ошибка" без уточнения в чём именно заключается ошибка, или обратно "При разборе документа был обнаружен недопустимый символ" без уточнения зачем этот документ вообще понадобился.
Как бы то ни было неполные сообщения об ошибках приводят к огромным потерям времени пользователя. Для меня лично был очень запоминающимся случай, когда я из-за небольшой ошибки в синтаксисе файла для mysql потерял пол дня на её поиски. При этом сам интерпретатор mysql наверняка "знал" в чём именно ошибка, но выдал мне куда более общее её описание.
Мне бы очень хотелось, чтобы каждый разработчик прочитавший этот текст запомнил: любая мелочь в программе приводящая к потере человеком более чем 5 минут времени абсолютно без продвижения в результате -- является багом интерфейса и требует исправления. Пользователи в свою очередь должны сообщать о таких своих потерях времени как о багах.
В идеале система должна предоставлять максимально полную информацию о любой ошибке и способах её устранения. Кроме того информация эта должна быть доступна без доступа к сети Интернет или любой подобной.
Естественно все эти мысли должны стать неотъемлемой частью концепции unDE.