Сколько информации в сообщениях об ошибках для обычных пользователей?

Question

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

• Сколько информации вы даете в сообщения об ошибках?

• Вы перенаправляете все ошибки, независимо от типа, к общей ошибке страница, или у вас есть небольшой набор страниц (404, 403, все остальные)?

• Вы даете коды ошибок, которые пользователь может ссылаться / дать вам только это ты понимаешь?

• Вы даете какие-либо технические детали?

Как я уже говорил, мои пользователи - нетехнические обычные люди Джо.

Answer 1

Показать приятную ошибку пользователю, Записать подробную ошибку для себя.

Answer 2

для фатальных ошибок, оставьте их короткими, чтобы они могли повторять их по телефону или электронной почте: не удается подключиться к базе данных и т. Д.

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

Я также всегда регистрирую все, параметры функции и любые внутренние значения, которые могут быть полезны.

Answer 3

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

Им, очевидно, не понадобятся трассировки стека и тому подобное, но для вас будет иметь смысл записать этот уровень детализации где-нибудь для диагностики и отладки.

Answer 4

Я пытаюсь сделать следующее:

1. убедитесь, что вы никогда не рискуете, чтобы пароли или строки подключения появлялись в сообщениях об ошибках.
2. Убедитесь, что ошибки записываются на постоянный носитель. Я предпочитаю базу данных, чтобы я мог делать запросы по временному диапазону и другим параметрам. Я не регистрирую 404 с.
3. Если приложение является внутренним приложением, которое не должно быть красивым, возможно, будет неплохо иметь информацию об ошибке на странице. Даже если вы регистрируете этот материал, приятно иметь возможность посылать вам скриншоты или копировать / вставлять ваши снимки по электронной почте.
4. Если 3 кажется неприятным, есть информация об ошибке, записанная в виде комментариев HTML. Тогда вы можете хотя бы просмотреть информацию, просмотрев источник.

Answer 5

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

Answer 6

Сообщения об ошибках вашего веб-приложения должны всегда (при минимум) быть ответами на эти 3 вопроса (в таком порядке):

1. Что случилось?

2. Почему это произошло?

3. Что с этим можно сделать?

Я использовал его много лет назад, от Apple «Рекомендации по интерфейсу пользователя: интерфейс Apple Desktop». Более новая версия . У Microsoft аналогичные рекомендации .

Это также позволяет легко писать их - это структурировано подход позволяет быстрее написать их, как можно просто ответь на вопросы.

Сообщения об ошибках также должны быть конкретными. Любая информация о котором знает веб-приложение и что пользователь может Нужно решить проблему, должно быть в сообщении об ошибке. (Печально известное) сообщение об ошибке «Произошла ошибка». это просто не приемлемо.

Дополнительно: дополнительная техническая информация, которую пользователь не может понять можно поставить в конце. Но это должно быть отмечено как таковой.

Answer 7

Когда дело доходит до отображения ошибок для конечного пользователя, я считаю хорошей практикой отображать код ошибки (чтобы я и администраторы знали, что это за ошибка) и типичное «ops что-то пошло не так, обратитесь к администратору»

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

Answer 8

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

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