Скільки інформації про помилку потрібно показати користувачеві?


38

Програми завжди можуть видавати помилки. У разі виникнення такої помилки слід повідомити користувача, оскільки те, що він попросив зробити програму, не вдалося.

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

Наприклад, мова, що підтримує винятки (.net, java), має тип винятку для спільного використання, де стався виняток, і дещо уточнююче повідомлення, яке слід подавати разом з винятком. Чи слід це також приховувати від користувача? Або нам це все одно показати? Або ми мусимо показати загальне повідомлення? чи ми мусимо показати одне з ряду повідомлень на основі того, що є основним винятком?

Відповіді:


34

що показати користувачеві. Чи слід це також приховувати від користувача?

Ви показуєте користувачеві, що для них діє.

Наприклад, якщо у вас є помилка, яка викликана деяким виключенням нульових покажчиків і більше помилки, ніж помилка користувача, ви не хочете повного пояснення, оскільки вони не можуть зробити нічого іншого.

Або нам це все одно показати? Або ми мусимо показати загальне повідомлення?

Показати виняток, оскільки вміст основного повідомлення про помилку для більшості користувачів безглуздий . Можливо, якщо ваша цільова база користувачів - це розробники, ви можете постійно показувати інформацію як повну помилку (можливо, у вас є внутрішня програма для автоматизованого тестування). Але в цілому користувачі не можуть зробити нічого іншого, навіть не маючи цього знання.

чи слід показувати одне із ряду повідомлень, виходячи з того, що є основним винятком?

Найкраща стратегія - це зробити наступне:

  • Інтерпретувати помилку в текст, який має значення для користувача.
    • Частина цього полягає в тому, "що може зробити користувач по-іншому?"
    • Якщо вони не можуть зробити нічого іншого, скажіть щось на кшталт "сталася несподівана помилка".
  • Додайте "необов'язковий" детальний опис помилки
  • Дозволити користувачам надсилати звіт про помилку (або робити це автоматично, залежно від бази користувачів)

Приклад

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

  1. Він показує "ось що трапилося" (несподівана помилка)
  2. Показує користувачеві, що робити (повторно відкрити пошту, навіть включає ярлик для цього)
  3. Також є "переглянути деталі", якщо комусь цікаво побачити повну технічну помилку
  4. Забезпечує повідомлення про подання звіту про помилку (див. Нижче)

Зауважте, що в деяких випадках ви можете зробити так, щоб звіт про помилки був автоматичним та автоматичним.


20
Я не погоджуюсь. Немає нічого такого настільки дратівливого, як програма, яка друкує "сталася помилка". на екран, а потім виходить. Щоразу, коли це трапляється, мені завжди цікаво, чому розробник був такий лінивий, щоби надрукувати таке неінформативне повідомлення. Поясніть користувачеві щось, щоб вони зрозуміли, що пішло не так у загальному розумінні, навіть якщо вони нічого з цим не можуть зробити. Найкращий сценарій - вони можуть подати повідомлення про помилку Google і, можливо, знайти рішення, яке описав хтось інший, що майже неможливо, якщо кожна інша помилка друкує одне загальне повідомлення.
Джон Бентлі

3
@JonBentley Ви дивитесь на це як на розробника, який хоче зрозуміти цей матеріал. Пересічний користувач просто переймається тим, що він повинен це зрозуміти, чого їм не потрібно.
deworde

12
@deworde Навпаки, я розглядаю це як користувача . Як користувач, я не хочу це розуміти в технічному плані, але я хочу достатньо інформації, щоб не відчувати, що людина, яка написала програмне забезпечення, некомпетентна ("сталася помилка", створюється враження, що розробник не став " я не знаю, що вони робили), і щоб я міг шукати відповіді. Якщо в кожній аварії йдеться про "помилку", пошук Google не допоможе мені. Унікальне повідомлення для кожної ситуації набагато частіше переносить мене на форум, де хтось інший мав ту саму проблему, і, можливо, вирішив її.
Джон Бентлі

3
@JonBentley кілька питань для розгляду. По-перше, основним моментом цієї відповіді є надання користувачеві дійсної інформації. Якщо це помилка, вони можуть виправити необхідність повідомити їм інформацію для її усунення. Це потрапляє в You show the user what is actionable for them. Якщо ви знаєте причину проблеми, то ви показуєте це користувачеві в описі. Але, як правило, якщо ви знаєте причину помилки, ви дізнаєтесь про рішення проблеми, щоб повідомити користувача про це належним чином.
Ендерленд

2
По-друге, ви сильно завищуєте середню здатність користувача до самостійного вирішення проблем. Переважна більшість населення - це те, що більшість розробників / програмістів / учасників Stack Exchange називають комп'ютерними неграмотними. Більшість із цих людей відверто кажучи не облаштовані для діагностики, усунення несправностей та вирішення проблем. Деталізація може насправді погіршити ситуацію, оскільки люди можуть неправильно інтерпретувати речі, які мали б повний сенс для розробників. Програмісти та кмітливі люди майже загалом не є цільовою демографічною
групою

12

Це залежить від того, хто такий користувач, і що вони можуть зробити з інформацією.

Як правило, спробуйте показати їм лише корисну інформацію про речі, які вони можуть вирішити. Трасування стека 40 рядків з регулярною помилкою виразу вгорі не дуже корисно. Набагато краще було б повідомлення, в якому сказано, що Дата повинна бути відформатована як "yyyy-mm-dd" . Ніщо інше, і користувач може не знати, як реагувати на помилку, і тоді вони можуть не захотіти користуватися вашим додатком, бо бояться, що це призведе до більш кричущих і страхітливих помилок (і так, користувачі, які не технічні, іноді лякаються стека сліди). І це може бути погано для бізнесу.

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

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


5
З програмою, яка надсилає журнали куди завгодно, не запитуючи мене, я б не був у порядку. Натомість діалогове вікно повідомлення про помилку повинно містити можливість повідомляти про помилку. Перед надсиланням звіту користувач повинен мати можливість переглянути будь-яку інформацію, включаючи трасування стека.
пієдар

1
@piedar: Це хороший момент.
FrustratedWithFormsDesigner

4
@piedar: У діалоговому вікні помилок натискання кнопки "Переглянути докладніші відомості" або посилання на файл журналу додатків - це, мабуть, хороший спосіб представити всі деталі горі енергокористувачам, які хочуть цю інформацію. Навіть прапорець "показати деталі за замовчуванням", якщо ви хочете перейти до проблеми його кодування. Але не всі користувачі захочуть це бачити, а деякі користувачі будуть відключені від цього.
FrustratedWithFormsDesigner

2
@Paddy: Ти маєш рацію, але: 1) Це приклад. : P 2) Можливо, я виправляв та прибирав такий код, ось чому це свідоме на моєму розумінні ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "І якщо він розробник, він може повторити помилку" .. - О, якби це було правдою :(
Blorgbeard

1

Повідомлення до користувачів повинні трактуватися так само, як створювати новий виняток для викидання - ви надаєте інформацію, яка їм знадобиться, щоб вирішити, що робити.

Це, звичайно, буде залежати від вашої програми та бази даних, але це повинно бути вашим основним принципом - ваш намір повинен полягати в наданні інформації, необхідної для "абонента", щоб визначити, що, якщо що, вони можуть зробити для успішного виконання бажаної дії . Якщо це щось просте, як помилка доступу до файлу, ви даєте шлях до файлу та повідомлення, що ви не можете отримати доступ до нього. Якщо це виключення з нульовим покажчиком, просто дайте загальне повідомлення про помилку.

Звичайно, буде більше повідомлень "не в змозі виконати потрібну дію", ніж буде таких, які користувач може насправді виправити, але це просто життя - більшість винятків - тому, що ми помилилися, а не тому, що користувач налаштував середовище неправильно.


1

Це поширена тема:

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

Я думаю, що відповідь - ти робиш обоє!

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

  • Що сталося.
  • Що ж тепер робити
  • Технічні деталі

Технічні деталі - це частина, яка містить інформацію як для розширених замовлень, так і для постійних користувачів під час повідомлення про проблему


0

Те, що ви хочете показати, залежить від того, наскільки ви соромляться за викручування.

Сенс полягає в тому, щоб отримати деталі відмови в технічній підтримці якомога швидше і плавніше. Це може означати, що ви надсилаєте файл журналу, включаючи стек стеку помилки, що закінчується, автоматично додому, або ви просите користувача натиснути кнопку, яка ініціює передачу. Можливо, через USB-накопичувач, якщо немає підключення до Інтернету.


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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.