Сколько информации об ошибке должно быть показано пользователю?

38

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

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

Например, язык, поддерживающий исключения (.net, java), имеет тип исключения, которым следует делиться, где произошло исключение, и несколько поясняющее сообщение, чтобы сопровождать исключение. Должно ли это быть скрыто от пользователя? Или мы все равно должны показать это? Или мы должны показать общее сообщение? или мы должны показать одно из нескольких сообщений, основанных на том, что является основным исключением?

Nzall
источник

Ответы:

34

что показать пользователю. Должно ли это быть скрыто от пользователя?

Вы показываете пользователю, что является для него действенным.

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

Или мы все равно должны это показать? Или мы должны показать общее сообщение?

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

мы должны показать одно из нескольких сообщений, основанных на том, что является основным исключением?

Лучшая стратегия заключается в следующем:

  • Интерпретировать ошибку в текст, который имеет смысл для пользователя.
    • Частично это "что пользователь может сделать по-другому?"
    • Если они не могут сделать что-то другое, скажите что-то вроде «произошла неожиданная ошибка».
  • Добавьте «необязательное» подробное описание ошибки
  • Разрешить пользователям отправлять отчет об ошибках (или делать это автоматически, в зависимости от базы пользователей)

пример

введите описание изображения здесь

  1. Показывает «вот что случилось» (неожиданная ошибка)
  2. Сообщает пользователю, что делать (повторно открывать Почту, даже включает ярлык для этого)
  3. Также есть «просмотр деталей», если кому-то интересно увидеть полную техническую ошибку
  4. Предоставляет уведомление об ошибке сообщение об ошибке (см. Ниже)

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

enderland
источник
20
Я не согласен. Нет ничего более раздражающего, чем приложение, которое печатает «произошла ошибка». на экран, а затем выходит. Всякий раз, когда это случается, я всегда задаюсь вопросом, почему разработчик был настолько ленив, чтобы напечатать такое неинформативное сообщение. Объясните что-нибудь пользователю, чтобы он мог понять, что пошло не так в общем смысле, даже если он ничего не может с этим поделать. В лучшем случае они могут отправить сообщение об ошибке в Google и, возможно, найти решение, описанное кем-то другим, что практически невозможно, если при каждой ошибке появляется одно и то же общее сообщение.
Джон Бентли
3
@JonBentley Вы смотрите на это как на разработчика, который хочет разобраться в этом. Обычный пользователь просто будет обеспокоен тем, что он должен понимать это, в чем он не нуждается.
deworde
12
@deworde Напротив, я рассматриваю это как пользователя . Как пользователь, я не хочу понимать это с технической точки зрения, но мне нужно достаточно информации, чтобы я не чувствовал, что человек, который написал программное обеспечение, некомпетентен («произошла ошибка», создается впечатление, что разработчик не не знаю, что они делали), и поэтому я могу искать ответы. Если каждый сбой говорит «произошла ошибка», то поиск в Google мне не поможет. Уникальное сообщение для каждой ситуации гораздо чаще приводит меня на форум, где кто-то другой имел такую ​​же проблему и, возможно, решил ее.
Джон Бентли
3
@JonBentley несколько моментов для рассмотрения. Во-первых, основной смысл этого ответа - вы даете пользователю полезную информацию. Если это ошибка, которую они могут исправить, нужно сообщить им информацию для ее устранения. Это попадает в You show the user what is actionable for them. Если вы знаете причину проблемы, то вы показываете это пользователю в описании. Но, как правило, если вы знаете причину ошибки, вы будете знать, как решить проблему, чтобы соответствующим образом проинформировать пользователя.
enderland
2
Во-вторых, вы сильно переоцениваете способность среднего пользователя самостоятельно решать проблемы. Подавляющее большинство населения - это то, что большинство разработчиков / программистов / пользователей Stack Exchange назвали бы компьютером неграмотным. Честно говоря, большинство из этих людей не способны диагностировать, устранять неполадки и решать проблемы. На самом деле, детализация может усугубить ситуацию, потому что люди могут неправильно истолковывать вещи, которые имеют смысл для разработчиков. Программисты и технически подкованные люди практически не являются целевой демографией для большинства приложений, к большому разочарованию всех присутствующих здесь ... :)
enderland
12

Это зависит от того, кто пользователь, и что они могут делать с информацией.

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

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

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

FrustratedWithFormsDesigner
источник
5
Я не буду в порядке с приложением, которое отправляет журналы в любом месте, не спрашивая меня. Вместо этого в диалоговом окне сообщения об ошибке должна быть возможность сообщить об ошибке. Пользователь должен иметь возможность просматривать любую информацию, включая трассировку стека, перед отправкой отчета.
Пьедар
1
@piedar: Это хороший момент.
FrustratedWithFormsDesigner
4
@piedar: Наличие кнопки «Подробнее» в диалоге ошибок или ссылки на файл журнала приложения - это, вероятно, хороший способ представить все подробности ужасов пользователям, которые хотят получить эту информацию. Даже флажок «показать детали по умолчанию», если вы хотите, чтобы его кодировать. Но не все пользователи захотят это видеть, и некоторые пользователи будут отключены.
FrustratedWithFormsDesigner
2
@Paddy: Вы правы, но: 1) Это пример. : P 2) Может быть, я исправлял и очищал такой код, вот почему он свеж в моем уме ...
FrustratedWithFormsDesigner
2
@NateKerkhofs "И если он разработчик, он может повторить ошибку" .. - о, если бы только это было правдой :(
Blorgbeard
1

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

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

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

jmoreno
источник
1

Это общая тема:

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

Я думаю, что ответ вы оба!

Порядок важен, хотя, и я рекомендую вам:

  • Что произошло.
  • что делать сейчас
  • Технические подробности

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

Майкл Даррант
источник
0

То, что вы хотите показать, зависит от того, насколько вам стыдно за то, что вы все испортили.

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

Мартин Маат
источник
0

Мне нравится обоснование принятого ответа, но я должен уважительно не согласиться, по крайней мере, с моей интерпретацией ограничения информации тем, что является «действенным» . Я хочу знать немного больше, чем это, как "неожиданную ошибку" .

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

Хотя я мало что знаю об авиации, скажем, мой рейс задерживается или отменяется, и единственное, что сотрудники говорят мне: «У нас произошла непредвиденная ошибка. Пожалуйста, подождите 3 часа для следующего рейса». По крайней мере, вы найдете меня немного более рассерженным клиентом в этих случаях, потому что, хотя это и не влияет на мой образ действий в любом случае, я просто хочу узнать немного больше о том, почему я являюсь неудобно, как платящий клиент.

Если они просто сказали: «У нас непростая погода» или «У нас произошла неотложная медицинская помощь во время нашего предыдущего полета», или неисправность оборудования или что-то еще, этого достаточно для меня, чтобы сочувствовать гораздо большему, чем «неожиданная ошибка» и быть немного более довольным сидеть без дела и ждать 3 часа следующего рейса. На самом деле, я бы даже предпочел, чтобы какой-нибудь техноаббл, который у меня над головой звучал, как «неожиданная ошибка» вроде: «Хорошо, слова, исходящие из твоего рта, попадают мне в ухо, но не доходят до центрального процессора. Но теперь я понимаю, что есть какая-то и я пойду, возьму немного кофе и сижу там! Надеюсь, вы, ребята, разберетесь с этим вопросом с этой штукой! "

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

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

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

Остальное, вероятно, очень специфично для ваших клиентов и конкретных потребностей. Но моя привлекательность, по крайней мере, для чего-то большего, чем «неожиданная ошибка».

Энергия Дракона
источник
Ну, это предвзятое мнение. Обычного пользователя не волнует, почему он не может сделать то, что он не может сделать. Их волнует только то, как и как они могут решить свою проблему.
gnasher729
«Обычного пользователя не волнует, почему он не может сделать то, что он не может сделать. Их волнует только то, смогут ли они решить свою проблему и каким образом». Если обычный пользователь даже не понимает, что такое файл или сервер, возможно, это так, но это все равно может быть связано с тем, что является «действенным», тогда, потому что они могут быть в состоянии коснуться вас по плечу и сказать: «Эй , это приложение говорит, что не может найти этот требуемый файл конфигурации ", или что-то в этом роде, где вы могли бы затем найти проблему и быстро исправить ее, например
Dragon Energy