Бестолковые сообщения об ошибках: вносим ясность
Попробуйте вспомнить, какие оригинальные и необычные сообщения об ошибках вам выдавали многочисленные программы и приложения, которыми вы пользуетесь. Наверняка у каждого из вас найдётся пара забавных примеров таких сообщений. В моём личном рейтинге на данный момент безусловный лидер — »Метод вернул что-то не то». Если существует шкала информативности сообщений, то приведённый пример по этой шкале стремится к нулю.
Здесь система, по сути, сообщает нам, что произошла ошибка. Больше никакой информации из этого текста мы не получим. Разве что узнаем, что где-то в недрах самой системы существует какой-то метод, который что-то не то вернул. Ценность этого знания для обычного пользователя нулевая.
Можно предположить, что этот текст — артефакт, оставшийся от процесса тестирования очередной функциональности. Некий флаг, оставленный разработчиком на этапе альфа-тестирования. Для программиста он явно имел какой-то смысл, но для пользователя — совершенно бесполезен.
К сожалению, подобные сообщения в наших программах и системах — не редкость. Разработчики оставляют в коде технические сообщения, а иногда просто ленятся написать хорошее информативное описание ошибки. А ведь такой текст не только помог бы пользователю в работе, но и снизил бы количество обращений в службу поддержки. Если пользователю внятно объяснить, что он сделал не так и как сделать правильно, то он наверняка справится с проблемой самостоятельно.
Каким же должно быть идеальное сообщение об ошибке?
Сообщение об ошибке на калькуляторе Электроника МК 52 / Wikimedia Commons
5 основных правил
В книге Сьюзан Уэйншенк »100 главных принципов дизайна» приведены основные правила написания информативного и полезного сообщения об ошибке:
Расскажите пользователю, что он сделал.
Объясните проблему.
Объясните, как исправить ошибку.
Используйте активный, а не пассивный залог.
Приведите пример.
В книге есть пример того, как не надо писать сообщения об ошибке:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
После варианта «Метод вернул что-то не то» даже такое сообщение может показаться довольно информативным. Однако в нём есть что улучшить. Но для начала давайте в порядке эксперимента попробуем его ухудшить — разберёмся, как не надо писать сообщения об ошибках.
«Вы хотите отправить разработчикам отчёт об ошибке в приложении?»
«Ok»
«Ну и ябеда!»
bash.im
Нам не привыкать — у нас за плечами многолетний опыт общения с разномастными продуктами отечественного софтостроения. Давайте уберём конкретику вовсе:
Счёт не может быть оплачен. Введены неправильные данные.
Чтобы ещё больше запутать пользователя, скроем от него причину ошибки:
Счёт не может быть оплачен.
Теперь приблизимся вплотную к нашему почти нулевому варианту:
Ошибка выполнения метода bill_payment.
Дальше для достижения антиидеала нам остаётся только убрать название метода и творчески преобразовать текст:
Неизвестная ошибка.
Интересно, не возникло ли у вас чувство дежавю, когда вы читали примеры в этом подразделе?
Сообщение об ошибке при попытке открыть Microsoft Office / Сайт microsoft.com
Добавляем информацию
В случае возникновения критической ошибки обновления:
1. Установите причину ошибки.
2. Устраните причину ошибки.
Документация Microsoft
Теперь давайте двигаться в другую сторону по нашей шкале — будем постепенно улучшать текст сообщения, руководствуясь правилами Сьюзан Уэйншенк.
Напомню исходный вариант сообщения из книги:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Для начала преобразуем исходный текст, чтобы его легче было воспринимать:
#402: Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Теперь расскажем пользователю, что он сделал не так:
#402: Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Выделим суть проблемы в отдельное предложение и явно объясним пользователю, что он должен сделать, чтобы её решить.
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Измените дату платежа так, чтобы она была позднее даты создания счёта.
Наконец, приведём конкретный пример. В данном случае нам известны даты и мы их можем использовать в тексте:
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа 25.07.2021 — она раньше, чем дата создания счёта 29.07.2021. Измените дату платежа так, чтобы она была позднее даты создания счёта 29.07.2021. Например, 30.07.2021.
Мы существенно улучшили сообщение об ошибке — учли все правила и почти приблизились к идеалу. Но давайте поднимемся на уровень выше и подумаем, можно ли сделать так, чтобы ошибка не возникала вовсе.
Лучшее сообщение об ошибке
Ошибка выполнения метода: «Метод выполнился без ошибок».
Есть фразы, которые сразу хочется выписать на жёлтый стикер и приклеить где-то рядом с монитором. Одна из таких фраз: «Лучшее сообщение об ошибке — отсутствие сообщения об ошибке». Иными словами, часто бывает проще не допустить возможности возникновения ошибки, чем её описывать.
В нашем примере никто не мешает разработчику сделать две вещи:
При смене даты счёта очистить поле с датой платежа.
В интерфейсе запретить ввод даты платежа позже заданной даты счёта.
Эти незначительные изменения в коде позволят избежать ошибки вовсе. И не нужно будет ломать голову над текстом сообщения.
К сожалению, таким простым способом решить проблему удаётся не всегда. Мы не можем полностью обезопасить приложение от возникновения ошибок. Но в наших силах сделать сообщения об ошибках более информативными и полезными.
Статья была впервые опубликована на другом ресурсе 30 июля 2021.
