как заставить пользователей читать сообщения об ошибках?

<p>если вы программируете для нетехнической аудитории, вы подвергаетесь высокому риску того, что пользователи не будут читать ваши тщательно сформулированные и информативные сообщения об ошибках, а просто нажмут на первую доступную кнопку, пожав плечами.</p><p>поэтому мне интересно, какие полезные практики вы можете порекомендовать пользователям, чтобы они действительно читали ваше сообщение об ошибке, а не просто отказывались от него. идеи, которые я могу придумать, будут соответствовать:</p><ul> <li>форматирование конечно поможет; может быть, простое короткое сообщение с кнопкой "узнать больше", которое приводит к более подробному сообщению об ошибке</li> <li>все сообщения об ошибках должны содержать ссылки на некоторые разделы руководства пользователя (что довольно сложно сделать)</li> <li>просто не выдавайте сообщения об ошибках, просто отказывайтесь выполнять задачу (несколько "яблочный" способ обработки пользовательского ввода)</li> </ul><p><em> редактировать: </em> аудитория, которую я имею в виду, - это довольно широкая пользовательская база, которая не использует программное обеспечение слишком часто и не является пленной (т. е. нет в программное обеспечение или узкое сообщество). более общая форма этого вопроса была задана на <a href="http://slashdot.org/">slashdot</a> , поэтому вы можете захотеть <a href="http://ask.slashdot.org/story/10/03/01/132219/how-do-you-get-users-to-read-error-messages">проверьте там</a> для некоторых ответов.</p>

<p>это отличный вопрос, достойный +1 от меня. вопрос, несмотря на свою простоту, охватывает многие аспекты характера конечных пользователей. здесь все сводится к ряду факторов, которые могут принести пользу вам и самому программному обеспечению, и, конечно, конечным пользователям.</p><ul> <li>не помещайте сообщения об ошибках в строке состояния - они никогда не будут их читать, несмотря на то, что они были изумлены цветами и т.д.… они всегда будут по ним скучать! как бы вы ни старались ... на одном из этапов тестирования пользовательского интерфейса win 95 перед его запуском ms провела эксперимент для чтения пользовательского интерфейса (<strong> ed </strong> <em> - следует отметить, что сообщение явно изложено в контексте "посмотри под стул" </em>), причем 100-долларовая банкнота приклеена к нижней части стула что субъекты сидели на ... никто не заметил сообщение в строке состояния!</li> <li>делайте сообщения короткими, не используйте пугающие слова, такие как "оповещение: система столкнулась с проблемой", конечный пользователь нажмет на кнопку паники и будет чрезмерно реагировать ...</li> <li>как бы вы ни старались, не используйте цвета, чтобы идентифицировать сообщение ... психологически это все равно, что размахивать красным флагом для быка!</li> <li>используйте нейтрально звучащие слова, чтобы передать минимальную реакцию и как действовать!</li> <li>может быть лучше показать диалоговое окно со списком нейтральных сообщений об ошибках и включить флажок, указывающий "хотите ли вы видеть больше этих сообщений об ошибках в будущем?", последнее, чего хочет конечный пользователь, - это работать в середине программного обеспечения, которое будет засыпано всплывающими сообщениями, они будут разочарованы и будут отключены приложением! если флажок был отмечен, зарегистрируйте его в файле вместо ...</li> <li>держите конечных пользователей в курсе того, какие сообщения об ошибках будут ... что подразумевает ... обучение и документирование ... теперь это сложное сообщение ... вы не хотите, чтобы они думали, что быть "проблемы" или "глюки" и что делать в случае этого ... они не должны знать, что будут возможные ошибки, действительно сложно.</li> <li>всегда, всегда, не бойтесь спрашивать обратную связь, когда происходит случайное происшествие, например: "когда появилась ошибка 1304, как вы отреагировали? какова была ваша интерпретация? - бонус с этим, конечный пользователь может дать вам более последовательное объяснение вместо "ошибка 1304, объект базы данных потерян!", вместо этого они могут сказать "я нажал на это так и вот, тогда кто-то случайно вытянул сетевой кабель машины ", это подскажет вам, что нужно с ним справиться, и может изменить ошибку, сказав:" ой, сетевое соединение отключено "... вы получаете дрейф.</li> <li>и последнее, но не менее важное: если вы хотите ориентироваться на международную аудиторию, примите во внимание интернационализацию сообщений об ошибках, поэтому сохраняйте их нейтральными, потому что тогда будет проще переводить, избегать синонимов, сленговых слов и т.д., которые перевод бессмысленный - например, <strike>указ</strike> форд, автомобильная компания продавала свою марку <strike>указ</strike> форд пинто, но заметил, что в южной америке не было продаж, оказалось, пинто был жаргоном для "маленького пениса" и, следовательно, продаж не было ...</li> <li>(<strong> ed </strong>) документировать список сообщений об ошибках, которые следует ожидать в отдельном разделе документации под названием "сообщения об ошибках" или "корректирующие действия" или аналогичные, перечисление номеров ошибок в правильном порядке с заявлением или двумя о том, как действовать ...</li> <li>(<strong> ed </strong>) благодаря <strong> <em> виктору хурдугачи </em> </strong> для его ввода, сохраняйте сообщения вежливыми, не заставляйте конечных пользователей чувствовать себя глупыми. это идет вразрез с ответом <strong> <em> джеком маркетти </em> </strong>, если база пользователей является международной ...</li> </ul><p><strong> редактировать: </strong> отдельное слово благодарности <strong> <em> gnibbler </em> </strong> кто упомянул еще один чрезвычайно важный момент!</p><ul> <li>позвольте конечным пользователям иметь возможность выбрать/скопировать сообщение об ошибке, чтобы они могли, если они этого пожелают, отправить электронное письмо в службу поддержки или группу разработчиков.</li> </ul><p><strong> редактировать # 2: </strong> мой плохой! ой, спасибо <strong> <em> danm </em> </strong>, который упомянул это об автомобиле, я перепутал название, оно был форд пинто ... мой плохой ...</p><p><strong> изменить # 3: </strong> выделены <strong> ed </strong> для обозначения дополнений или дополнений и зачисляются на счет других за их вклад ...</p><p><strong> редактировать # 4: </strong> в ответ на комментарий кена - вот мое мнение ... нет, нет, используйте нейтральные стандартные цвета windows ... не ходите для ярких цветов! придерживайтесь обычного серого цвета фона с черным текстом, который является нормальным стандартным руководством по графическому интерфейсу в спецификациях microsoft. см. <a href="http://msdn.microsoft.com/en-us/library/aa511258.aspx">рекомендации по ux</a> (<strong> ed </strong>).</p><p>если вы настаиваете на ярких цветах, по крайней мере, учитывайте потенциальных дальтоников, т. е. <em> доступность, которая является еще одним важным фактором </em> для тех, кто имеет инвалидность, сообщения об ошибках, удобные для увеличения экрана дальтонизмом, страдающим альбиносом, они могут быть чувствительны к ярким цветам, а также эпилептикам ... которые могут страдать от определенных цветов, которые могут вызвать приступ ...</p>

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

<p>краткий ответ: вы не можете.</p><p>менее короткий ответ: сделайте их видимыми, актуальными и контекстуальными (выделите то, что они испортили). но, тем не менее, вы ведете проигранную битву. люди не читают на экранах компьютеров, они сканируют, и их научили нажимать кнопки, пока диалоговые окна не исчезнут.</p>

<p>оповещения/всплывающие окна раздражают, поэтому все нажимают первую кнопку, которую они видят.</p><p><strong>сделать это <em> меньше </em> раздражает</strong>. пример: если пользователь неправильно ввел дату или ввел текст с ожидаемыми числами, то <strong>не</strong> всплывающее сообщение, просто выделите поле и напишите сообщение где-нибудь вокруг него.</p><p><strong>создайте собственное окно сообщения</strong>. никогда не используйте окно сообщений по умолчанию системы, например, окна сообщений windows xp сами по себе раздражают. создайте новое цветное окно сообщения с цветом фона, отличным от системного по умолчанию.</p><p><strong>очень важно: не настаивайте</strong>. некоторые окна сообщений используют модальное диалоговое окно и настаивают на том, чтобы вы читали его, это очень раздражает. если вы можете заставить окно сообщения отображаться как предупреждающее сообщение, было бы лучше, например, сообщения переполнения стека, которые появляются прямо вверху страницы, информируя, но не раздражая.</p><p><strong>update</strong><br> <strong>сделать сообщение значимым и полезным</strong>. например, не пишите что-то вроде: "клавиатура не найдена, нажмите f1 для продолжения".</p>

<p>в зависимости от вашей пользовательской базы, написание смешных/грубых/личных сообщений об ошибках может работать отлично.</p><p>например, я написал приложение, которое позволило нашим <a href="http://en.wikipedia.org/wiki/human\_resources">hr</a> людям лучше отслеживать даты найма/увольнения сотрудников. [мы были маленькой компанией, очень спокойной].</p><p>когда они вводили неправильные даты, я писал:</p><blockquote> <p><strong> эй, тупица, научись вводить дату! </strong></p> </blockquote><p>правка: конечно, более полезным сообщением является: "пожалуйста, введите дату в виде мм/дд/гггг" или, возможно, в коде, чтобы попытаться выяснить, что они ввели, и если они ввели "бла", чтобы показать ошибку. тем не менее, это было очень небольшое приложение для человека, которого я знал лично. следовательно, снова люди, прочитайте первую строку этого поста: <em> в зависимости от вашей пользовательской базы ... </em></p><p>недавно я работал над проектом art institute, поэтому сообщения об ошибках были направлены на аудиторию, например:</p><blockquote> <p>большая часть искусства до периода барокко была без знака. тем не менее, мы сейчас за пределами периода барокко, поэтому все поля должны быть заполнены.</p> </blockquote><p>по сути, подготовьте его для своей аудитории, если это вообще возможно, и избегайте скучных, как все неземных общих ошибок, таких как: "пожалуйста, введите адрес электронной почты" или "пожалуйста, введите действительный адрес электронной почты".</p>

<p>мы поместили простой запоминающийся рисунок в поле ошибки: не значок, довольно большое растровое изображение и ничего похожего на стандартные значки сообщений windows. никто никогда не сможет вспомнить формулировку окна сообщения (большинство даже не прочитает его, если в поле есть кнопка "ок", которую они могут нажать), но большинство людей действительно помнят изображение, которое они видели. поэтому наши сотрудники службы поддержки могут спросить клиента: "вы видели парня, пьющего кофе?" или "ты видел пустой стол?" по крайней мере, так мы примерно знаем, что пошло не так.</p>

<p>лучший дизайн пользовательского интерфейса будет там, где вы практически никогда не будете показывать сообщение об ошибке. программное обеспечение должно адаптироваться к пользователю. при таком дизайне сообщение об ошибке будет новым и привлечет внимание пользователей. если вы попадаете пользователю с такими бессмысленными диалогами, вы явно обучаете их игнорировать ваши сообщения.</p>

<p>по моему мнению и опыту, это опытные пользователи, которые не читают сообщения об ошибках. нетехническая аудитория, которую я знаю, внимательно читает каждое сообщение на экране, и проблема на этом этапе в основном в следующем: они этого не понимают.</p><p>этот момент может быть причиной вашего опыта, потому что в какой-то момент они перестанут их читать, потому что "они все равно не понимают", поэтому ваша задача проста:</p><p>сделайте сообщение об ошибке как можно более понятным и сохраните техническую часть под капотом.</p><p>например я передаю сообщение как это:</p><blockquote> <p>ora-00237: операция моментального снимка запрещена: вновь создан управляющий файл причина: была предпринята попытка вызвать cfilemakeandusesnapshot с подключенным в данный момент управляющим файлом, который был недавно создан с помощью create controlfile. действие: смонтируйте текущий управляющий файл и повторите операцию.</p> </blockquote><p>что-то вроде:</p><blockquote> <p>этот шаг не может быть обработан из-за временных проблем с базой данных. пожалуйста, свяжитесь (ваш администратор | служба поддержки | любой, кто может связаться с разработчиком или администратором для решения проблемы). приносим извинения за неудобства.</p> </blockquote>

<p>покажите пользователям, что сообщение об ошибке <strong> имеет значение </strong>, и это способ <strong> оказать им помощь </strong> и они это прочтут. если это просто жаргонное или общее бессмысленное сообщение, они научатся быстро их отклонять.</p><p>я узнал, что очень полезно включать диалоговое окно с сообщением об ошибке с действием по умолчанию для отправки (например, по электронной почте) подробной диагностической информации. если вы быстро ответите на эти письма с ценной информацией или обходным путем, они будут вам поклоняться.</p><p>это также отличный инструмент обучения. в будущих версиях вы можете решить известные проблемы или, по крайней мере, предоставить информацию об обходном пути на месте. до этого пользователи узнают, что это сообщение вызвано x, а проблема может быть решена y - и все потому, что им кто-то объяснил.</p><p>конечно, это не будет работать в крупномасштабных приложениях, но очень хорошо работает в корпоративных приложениях с несколькими сотнями пользователей, а также в гибкой, быстро выпускаемой ранней версии среде.</p><p>правка:</p><p>поскольку у вас широкая база пользователей, я рекомендую предоставить программное обеспечение, которое будет выполнять то, что пользователи могут/могут ожидать от него, например. не показывать им сообщение об ошибке, если номер телефона не отформатирован, переформатируйте его, если это не так.</p><p>мне лично нравится программное обеспечение, которое <a href="https://rads.stackoverflow.com/amzn/click/com/0789723107">не заставляет меня думать</a> , и когда иногда (разработчик) вы ничего не можете сделать, чтобы интерпретировать мое намерение, предоставить очень хорошо написанные (и проверенные реальными пользователями) сообщения.</p><p>общеизвестно, что <strong> люди не читают документацию </strong> (читали ли вы инструкции подряд, когда вы подключили бытовой прибор?), они пытаются способ получить результаты быстро, когда не удалось, вы должны привлечь их внимание (например, отключить кнопку по умолчанию на некоторое время) с <strong> значимым </strong> и <strong> полезная </strong> информация. они не заботятся о вашем отказе программного обеспечения, они хотят получить результаты, сейчас.</p>

<p> <a href="http://www.codinghorror.com/blog/2009/03/why-cant-error-messages-be-fun.html">сделать их веселыми</a> . (это показалось актуальным, учитывая сайт, на котором мы находимся :))</p>

<p>если вы не можете предоставить пользователю простой обходной путь, даже не показывайте пользователю сообщение об ошибке. в этом нет никакого смысла, так как 90% пользователей не заботятся о том, что они говорят.</p><p>с другой стороны, если вы <em>можете</em> на самом деле показать пользователю полезный обходной путь, то один из способов заставить его прочитать его - активировать кнопку ok через 10 секунд или около того. , что-то вроде того, как firefox делает это всякий раз, когда вы пытаетесь установить новый плагин.</p><p>если это полный сбой, из которого вы не можете корректно восстановиться, то проинформируйте пользователя очень непрофессионалом, говоря:</p><p>"<strong> мне жаль, что мы облажались, мы хотели бы отправить некоторую информацию об этом сбое, вы позволите нам сделать это? да/нет </strong>"</p><p>кроме того, постарайтесь не делать ваши сообщения об ошибках длиннее предложения. когда люди (включая меня) видят целый абзац, говорящий об ошибке, мой разум просто отключается.</p><p>с таким большим количеством социальных сетей и информационной перегрузки ум людей замирает, когда они видят стену текста.</p><h2>правка:</h2><p>кто-то однажды также недавно предложил использовать комиксы вместе с тем сообщением, которое вы хотите показать. например, что-то из <a href="http://en.wikipedia.org/wiki/dilbert">дилберт</a> , которое может быть близко к типу ошибки, которую вы можете иметь.</p>

<p>смотрите также ответы пользователей slashdot <a href="http://ask.slashdot.org/comments.pl?sid=1566754">здесь</a> .</p>

<p>я хотел бы добавить одну вещь.</p><p>используйте глаголы для кнопок действий, чтобы закрыть сообщения об ошибках, а не восклицания, например, не используйте "ok!" "закрыть" и т.д.</p>

<p>один хороший совет, который я узнал, заключается в том, что вы должны написать диалоговое окно, как в газетной статье. не в смысле размера, а в смысле важности. позволь мне объяснить.</p><p>вы должны написать самые важные вещи для чтения, во-первых, и предоставить более подробную информацию, во-вторых.</p><p>другими словами, это не хорошо</p><pre><code>there was a problem loading the file, the file might have been deleted, or it might be present on a network share that you don't have access to at your present location. do you want to retry opening the file? </code></pre><p>вместо этого измените порядок:</p><pre><code>problem loading file, do you want to retry? there was a problem loading the file, the file might have been deleted, or it might be present on a network share that you don't have access to at your present location. </code></pre><p>таким образом, пользователь может читать столько, сколько он хочет, или беспокоиться, и все еще иметь представление о том, что спрашивают.</p>

<p>я часто отображаю ошибку красным цветом (когда дизайн это позволяет).</p><p>красный означает "предупреждение" и т.д., поэтому его чаще читают.</p>

<p>для начала напишите сообщения об ошибках, которые пользователи могут понять. "ошибка: 1023" не является хорошим примером. я думаю, что лучше регистрировать ошибку, чем показывать ее пользователю с "причудливым" кодом. или, если регистрация невозможна, предоставьте пользователям правильный способ отправить сведения об ошибке в службу поддержки.</p><p>кроме того, будьте коротки и достаточно ясны. не включайте некоторые технические детали. не показывайте им информацию, которую они не могут использовать. если возможно, предоставьте способ устранения ошибки. если не указан маршрут по умолчанию, его следует использовать.</p><p>если ваше приложение является веб-приложением, то разработка пользовательских страниц ошибок - хорошая идея. они меньше нагружают пользователей, например so. вы можете получить некоторые идеи, как создать хорошую страницу ошибок здесь: <a href="http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/">http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/</a> </p>

<p>мы сказали пользователям, что с их менеджером связались (что было ложью). это работало слишком хорошо и должно было быть удалено.</p>

<p>хорошо, чтобы ответить на ваш вопрос напрямую: не заставляйте ваших программистов писать ваши сообщения об ошибках. если вы последуете этому совету, вы в совокупности сэкономите тысячи часов работы пользователя и производительности и миллионы долларов на затратах на техническую поддержку.</p><p>однако настоящая цель должна заключаться в разработке вашего приложения, чтобы пользователи не могли ошибаться. не позволяйте им предпринимать действия, которые приводят к ошибкам и требуют от них резервного копирования. в качестве простого примера, в веб-форме, которая требует заполнения всех ее полей, вместо появления сообщения об ошибке, когда пользователь нажимает кнопку "отправить", не включайте кнопку "отправить", пока все поля не содержат допустимое содержимое. это означает больше работы на обратной стороне, но это приводит к лучшему взаимодействию с пользователем.</p><p>конечно, это немного идеальный мир. иногда программные ошибки неизбежны. когда они происходят, вам необходимо предоставить четкую, полную и полезную информацию, и, самое главное, не раскрывать систему для пользователя и не обвинять пользователей в их действиях.</p><p>хорошее сообщение об ошибке должно содержать:</p><ol> <li>в чем проблема и почему это произошло.</li> <li>как решено проблему.</li> </ol><p>одна из худших вещей, которые вы можете сделать, это просто передать системные сообщения об ошибках пользователям. например, когда ваша программа java выдает исключение, не просто передавайте программисту пользовательский интерфейс и представляйте его пользователю. поймайте это и получите четкое сообщение, созданное вашим разработчиком помощи пользователю, которое вы можете представить своему пользователю.</p><p>на моей последней работе мне посчастливилось работать с командой программистов, которые не думали бы писать свои собственные сообщения об ошибках. каждый раз, когда они оказывались в ситуации, когда это требовалось, и программа не могла быть разработана, чтобы этого избежать (часто из-за ограниченных ресурсов), они всегда приходили ко мне, объясняли, что им нужно, и позволяли мне создавать сообщение об ошибке, которое был понятен и придерживался фирменного стиля. если бы это было мышлением по умолчанию для каждого программиста, компьютерный мир был бы гораздо лучше.</p>

<p><strong>меньше ошибок</strong></p><p>если приложение вызывает у вас рвоту на регулярной основе, вы становитесь невосприимчивыми к нему, и ошибки становятся раздражающим фоном для музака. если ошибка является редким событием, она привлечет больше внимания.</p><p>отмените все, что не имеет большого значения, выбросьте все эти предупреждения, найдите способы понять намерения пользователя, по возможности принимайте решения. у меня есть несколько приложений, которые я продолжаю оптимизировать таким образом. разработчики видят каждую ошибку как важную, но это не так с точки зрения пользователя. найдите общий ответ пользователя на проблему и запишите его, разверните как <em> ваш </em> ответ.</p><p>если вам нужно поднять ошибку: кратко, кратко, низкий коэффициент терроризма, без восклицательных знаков. абзацы <em> терпят неудачу </em>.</p><p>там нет серебряной пули, но вам нужно социальный инженер, чтобы ошибки были важны.</p>

<p>добавление кнопки "дополнительно", которая позволяет использовать некоторые технические детали, будет стимулировать их чтение для той части целевой аудитории, которая считает себя технической</p>

<p>я прочитал кандидата на самое ужасное решение на slashdot:</p><blockquote> <p>мы обнаружили, что единственный способ заставить пользователей брать на себя ответственность за ошибки - это назначить им штраф за то, что они заставили ошибку исчезнуть. для начинающих, где это возможно, ошибка фактически не закрывается для них, если мы не введем пароль администратора, чтобы он исчез, и если они перезагрузятся, чтобы избавиться от него (диспетчер задач отключен на всех клиентских пк), машина не откроет приложение, которое зависало в течение 15 минут. конечно, все это зависит от типа пользователей, с которыми вы имеете дело, так как более технически опытные пользователи не примут такую систему, но после буквально года пользователи будут нести ответственность за сбои и убедиться, что ит-отдел знает чтобы устранить проблему до того, как ей станет слишком трудно управлять, это единственные шаги, которые сработали. теперь все наши конечные пользователи знают, что если они проигнорируют ошибки, они сами пострадают за это.</p> </blockquote>

<p>как насчет создания состояния кнопки "нажмите здесь, чтобы поговорить со специалистом службы поддержки, который поможет вам с этой проблемой".</p><p>есть много сайтов, которые предоставляют возможность говорить с реальным человеком.</p>

<p>несмотря на все рекомендации в принятом ответе, мои пользователи продолжали нажимать на первую кнопку, которую могли найти. так что теперь я покажу это:</p><p><img src="https://i.stack.imgur.com/qq6hm.png" alt="read this!"></p><p>пользователь <em>имеет</em> сделать выбор до появления кнопки ок</p><p><img src="https://i.stack.imgur.com/2cssv.jpg" alt="chose the correct option"></p><p>если он выберет третий вариант, он может продолжить, в противном случае приложение закроется.</p>

<p>я бы посоветовал вам оставить отзыв (заявив, что пользователь допустил ошибку) сразу после ошибки. (например, при вводе значения в поле даты, проверьте значение и, если оно неверно, сделайте поле ввода визуально другим).</p><p>если на странице есть ошибки (я больше занимаюсь веб-разработкой, поэтому я называю ее "страницей", но ее также можно назвать "формой"), покажите "сводку ошибок", пояснив, что были ошибки и маркированный список того, что именно ошибки произошли. однако, если в сообщении содержится более 5-6 слов, они не будут прочитаны/поняты.</p>

<p>"внимание! внимание! если вы не прочитаете сообщение об ошибке, вы умрете!"</p>