如何让用户阅读错误信息？
如果您为非技术用户编程，您会发现自己处于高度风险之中，用户不会阅读您认真的措辞和启发性的错误消息，而只需点击第一个可用的沮丧的button即可。
所以，我想知道什么好的做法，你可以推荐帮助用户实际阅读你的错误信息，而不是简单地放弃一边。 我能想到的想法会落在以下几点：
- 格式化当然有帮助; 也许是一个简单的短消息，带有“了解更多”button，导致更长，更详细的错误消息
- 将所有错误消息链接到用户指南的某个部分（有点难以实现）
- 只是不要发出错误信息，只是拒绝执行任务（一种有点“苹果”的处理用户input的方式）
编辑：我想到的观众是一个相当广泛的用户群，不太频繁地使用软件，不是俘虏（即没有内部软件或狭窄的社区）。 这个问题的一个更通用的forms被问到slashdot ，所以你可能想检查一些答案。
这是一个值得我从+1的优秀问题。 这个问题尽pipe很简单，涵盖了最终用户性质的许多方面。 这归结于许多因素，这些因素会使您和软件本身受益，当然也有利于最终用户。
- 不要在状态栏中放置错误信息 – 尽pipe有颜色等等，他们将永远不会读取它们….他们总是会错过它们！ 不pipe你有多努力，都会尝试…在Win 95 UItesting开始之前的一个阶段，MS进行了一个实验来阅读UI（ 编辑 – 应该注意的是，这个消息在“看在椅子下面 ），一张100美元的钞票贴在椅子的下面，表示对象正坐在…没有人在状态栏中发现消息！
- 使信息简短，不要使用吓唬的话，如“警报：系统遇到问题”，最终用户将打到恐慌button，将过度反应…
- 不pipe你怎么努力，都不要用颜色去识别这个信息……心理上，这就像是给公牛挥动一面红旗！
- 使用中立的声音来传达最小的反应，以及如何进行！
- 最好是显示一个列出中性错误信息的对话框，并在最后一个用户想要的最后一个工作内容中join一个checkbox，指示“您是否希望将来会看到更多这些错误信息？”在popup消息的软件的中间，他们会感到沮丧，并将被closures的应用程序！ 如果勾选了checkbox，请将其logging到文件中。
- 让最终用户了解将会出现什么样的错误信息……这意味着……培训和文档logging……现在，这是一个棘手的问题……你不希望他们认为会有是“问题”还是“小故障”，以及如果发生这种情况……他们一定不知道会有可能的错误，确实是棘手的。
- 总是，不要在平安的时候要求反馈 – 比如“当错误号1304出现了，你是怎么反应的？ 你的解释是什么？ – 这个奖金，最终用户可能会给你一个更为一致的解释，而不是'错误1304，数据库对象丢失'，而不是他们可以说'我点击这个那么有人不小心把机器的网线拔了，这样就会提示你不得不处理这个问题，并且可能会修改错误，说出“Ooops，networking连接断开”……你得到了漂移。
- 最后但并非最不重要的一点，如果你想瞄准国际观众，考虑到国际化的错误信息 – 因此，这就是为什么保持中立，因为这样会更容易翻译，避免同义词，俚语等，这将使翻译毫无意义 – 例如，汽车公司
菲亚特·福特（FiatFord）出售他们的品牌菲亚特·福特·平托（FiatFord Pinto），但注意到南美没有销售，结果是，平托是一个“小阴茎”的俚语，因此没有销售… - （ ed ）在标题为“错误消息”或“纠正措施”或类似文档的单独章节中logging预期的错误消息列表，并按照正确的顺序列出错误编号，并附上关于如何继续的声明。 ..
- （ ed ）感谢Victor Hurdugaci的投入，保持信息的礼貌，不要让最终用户感到愚蠢。 这与杰克·马尔凯蒂 （ Jack Marchetti）的回答相反，如果用户群是国际的话。
编辑：感谢gnibbler谁提到另一个极其重要的一点特别的话！
- 允许最终用户能够select/复制错误消息，以便他们如果愿意，可以通过电子邮件发送给帮助支持团队或开发团队。
编辑＃2：我的不好！ 哎呀，感谢DanM提到的那辆车，我把名字弄混了，那是Ford Pinto …我的坏…
编辑＃3： ed已经突出显示加法或加法，并记入他人的input…
编辑＃4：回应肯的评论 – 这是我的采取…不，它不是，使用中性标准的Windows颜色…不要去浮华的颜色！ 坚持正常的灰色背黑色文本，这是微软规范中的常规标准GUI指南。参见用户体验指南 （ 编者 ）。
如果你坚持浮华的色彩，至less要考虑到潜在的色盲用户，即残疾人的另一个重要因素 ，屏幕放大友好的错误信息，色盲，遭受白化病的人，他们可能对浮华的颜色敏感，癫痫也可能会受到特定颜色的刺激
向他们显示消息。 尽职尽责，但将每个错误logging到一个文件中。 用户不记得他们在做什么，或者事件发生后几秒钟的错误信息，就像是看pipe人员的目击者账户。
提供一个很好的方法，让他们通过电子邮件或上传日志给你，这样你可以协助他们调和问题。 如果这是一个networking应用程序：甚至更好的是，您甚至可以在任何人报告问题之前收到有关情况的信息。
简短的回答：你不能。
简短的回答：让他们可见，相关和上下文（突出显示他们搞砸了）。 但是，你仍然在战斗中失败。 人们不会在计算机屏幕上阅读，他们会扫描，并且他们已经被训练去点击button，直到对话框消失。
我们把一个简单的令人难忘的graphics放在错误框中：不是一个图标，一个相当大的位图，没有像标准的Windows消息图标。 没有人能够记得一个消息框的措辞（如果框中有一个“确定”button，大多数人甚至不会阅读它），但大多数人都记得他们看到的图片。 所以我们的支持人员可以问客户：“你见过喝咖啡的人吗？ 或者“你看到空桌子了吗？” 至less我们知道大概出了什么问题。
根据您的用户群，写有趣/粗鲁/个人错误信息可以很好地工作。
例如，我写了一个应用程序，让我们的人力资源人员更好地跟踪员工的雇佣/雇佣date。 [我们是一个小公司，非常悠闲]。
当他们input错误的date时，我会写：
嘿哑巴屁股，学习如何inputdate！
编辑：当然更有用的消息是说：“请inputdate为mm / dd / yyyy”，或者在代码中试图找出他们input的内容，如果他们input“blahblah”显示错误。 但是，对于我个人认识的人力资源人员来说，这是一个非常小的申请。 因此，再次的人，阅读这篇文章的第一行： 根据您的用户群…
我最近在一个艺术学院的项目上工作，所以错误信息是面向观众的，比如：
巴洛克时代之前的大部分艺术作品都没有签名。 但是，现在我们已经超越了巴洛克时代，所有的领域都必须完成。
如果可能的话，基本上要把它传达给你的听众，并避免所有非常普遍的错误，例如：“请input电子邮件”或“请input有效的电子邮件”。
警报/popup窗口很烦人，这就是为什么每个人都击中他们看到的第一个button。
让它less烦人 。 例如：如果用户错误地input了date，或者input了一个需要数字的文本，那么不要popup一条消息，只需突出显示该字段并在其周围写入消息。
制作自定义消息框 。 永远不要使用系统的默认消息框，例如Windows XP消息框自己讨厌。 创build一个新的彩色消息框，使用与系统默认不同的背景颜色。
非常重要：不要坚持 。 有些消息框使用modal dialog，并坚持让你阅读它，这是非常烦人的。 如果您可以使消息框显示为警告消息，则会更好，例如，显示在页面顶部的堆栈溢出消息，通知但不会令人讨厌。
UPDATE
使信息有意义且有帮助 。 例如，不要写下类似“找不到键盘，按F1继续”。
最好的UIdevise将是你几乎从不显示错误信息的地方。 软件应该适应用户。 有了这样的devise，错误信息将是新颖的，将吸引用户的关注。 如果你用这样的无意义的对话来胡说用户，你明确地训练他们忽略你的信息。
在我看来，经验是那些不阅读错误信息的高级用户。 我认识的非技术类读者最仔细地阅读屏幕上的每一条消息，这个问题大部分是：他们不理解。
这一点可能是你的经验的原因，因为在某些时候，他们将停止阅读，因为“他们不明白它”，所以你的任务很容易：
使错误信息尽可能容易理解，并将技术部分置于隐蔽之中。
例如，我传递一个消息，像这样：
ORA-00237：不允许快照操作：新创build的控制文件原因：尝试调用cfileMakeAndUseSnapshot与当前装载的控制文件是新创build的CREATE CONTROLFILE。 操作：装载当前控制文件并重试操作。
像这样的东西：
由于数据库暂时出现问题，无法处理此步骤。 请联系（您的pipe理员|帮助台|任何可以联系开发人员或pipe理员解决问题的人员）。 抱歉给你带来不便。
向用户显示错误信息有意义 ，这是向他们提供帮助的一种方式，他们会阅读它。 如果这只是行话或一般的无意义的消息，他们将学习，消除他们quicly。
我已经了解到，这是非常好的做法，包括一个错误对话框默认行动发送（例如通过电子邮件）详细的诊断信息，如果你迅速回应这些有价值的信息或解决方法的电子邮件，他们会崇拜你。
这也是一个很好的学习工具。 在将来的版本中，您可以解决已知问题，或至less提供就地解决方法信息。 在此之前用户将会知道这个消息是由X引起的，这个问题可以通过Y来解决，因为有人向他们解释了这个问题。
当然这不适用于大规模的应用程序，但对于几百个用户的企业应用程序来说效果很好，而且在精益敏捷的情况下，经常会发布早期版本的环境。
编辑：
由于你有广泛的用户基础，我build议提供软件，做用户可以/期望它做的，例如。 如果电话号码格式不正确，请不要显示他们的错误信息，请重新格式化。
我个人喜欢软件， 不会让我思考 ，偶尔也没有什么（开发人员）能够解释我的意图，提供一个写得很好（并由实际用户审阅）的消息。
众所周知， 人们不会阅读文档 （当你插入家用电器时，你是否连续阅读指令？），他们尝试一种方式来快速获得结果，当失败时你必须抓住他们的注意力（例如，禁用默认button一段时间）与有意义和有用的信息。 他们不关心你的软件失败，他们现在想要得到结果。
让他们开心 。 （这似乎是相关的，给我们的网站:)）
要开始，写入用户可以真正理解的错误消息。 “错误：1023”不是很好的例子。 我认为更好的方法是logging错误，而不是用一些“奇特”的代码向用户显示。 或者如果不能logging日志，请给用户正确的方式将错误详细信息发送给支持部门。
另外，要简短明了。 不要包含一些技术细节。 不要向他们展示他们不能使用的信息。 如果可能的话，为错误提供解决方法。 如果不提供默认路由，则应该采取。
如果您的应用程序是一个Web应用程序，devise自定义错误页面是一个好主意。 他们比较less强调用户，以SO为例。 你可以得到一些想法如何在这里devise一个好的错误页面： http : //www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/
有一件事我想补充。
使用动词作为你的动作button来closures你的错误信息，而不是感叹号，例如不要使用“OK”。 “closures”等
我学到的一个好的提示是，你应该写一个像报纸文章的对话框。 不在规模意义上，而是在重要意义上。 让我解释。
你应该写最重要的东西来阅读，第一，并提供更详细的信息第二。
换句话说，这是不好的：
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? 相反，更改顺序：
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.
这样，用户可以随心所欲地阅读，或者烦恼，并且仍然对所要求的内容有所了解。
请参阅Slashdot的用户在这里的回应。
除非你能提供给用户一些简单的解决方法，否则不要麻烦向用户显示错误信息。 没有意义，因为90％的用户不会在乎它说什么。
另一方面如果你真的可以向用户显示一个有用的解决方法，那么强制他们读取它的一种方法是在10秒左右之后使“确定”button变为可用。 当你试图安装一个新的插件的时候，Firefox会怎么做。
如果这是一个完全崩溃，你不能优雅地恢复，然后通知用户非常俗语说：
“ 对不起，我们搞砸了，我们想发一些关于这次事故的信息，你能让我们这样做吗？是/否 ”
另外，尽量不要让错误信息比一个句子长。 当人们（包括我在内）看到一整段关于错误的话题时，我的思绪就会closures。
有了这么多的社交媒体和信息超载，当人们看到一堵文字的时候，心灵就会冻结。
编辑：
最近也有人build议使用连环画以及任何想要展示的信息。 比如说从迪尔伯特那里得到的东西可能接近你可能有的错误types。
根据我的经验：您不会让用户（尤其是非技术用户）阅读错误消息。 不pipe大家多么清楚，可以理解，大胆，红色和闪烁的信息，大多数用户只会点击他们不习惯的任何东西，即使是“你真的要删除所有东西吗？”。 我看到用户点击“窗口closures”图标，而不是“确定”或“取消”，即使他们甚至不知道他们select了哪个选项…
如果你真的需要强制用户阅读你所显示的内容，我会build议一个JavaScript的倒计时，直到一个button是可点击的。 这样用户将希望利用等待时间来真正阅读他应该的。 但要小心：大多数用户会更加恼火:)
我还喜欢你的“阅读更多”链接的想法，虽然我怀疑是否会让用户更感兴趣，只是想通过一切手段摆脱消息…
只是为了logging：有些用户可以阅读错误信息，但是很害怕，他们不会做任何事情。 我曾经有一个支持电话，客户会给我看一个错误信息，问我，他该怎么做。 “那么，你有什么select？”我问。 “窗户只有一个'OK'button。”他回答。 … mmh，很难:)
我经常以红色显示错误（当devise允许的时候）。
红色代表“警惕”等，所以更经常阅读。
那么，直接回答你的问题：不要让你的程序员写错误信息。 如果遵循这一条build议，那么累计可以节省数千小时的用户焦虑和生产力，以及数百万美元的技术支持成本。
但是，真正的目标应该是devise你的应用程序，以便用户不会犯错误。 不要让他们采取导致错误按摩的行为，并要求他们备份。 作为一个简单的例子，在一个web表单中，需要填写所有的字段，而不是在用户点击发送button时popup一个错误消息，直到所有的字段都包含有效的内容为止，不要启用发送button。 这意味着更多的背面工作，但它会带来更好的用户体验。
当然，这是一个理想的世界。 有时候，程序错误是不可避免的。 当它们发生时，您需要提供清晰，完整和有用的信息，最重要的是，不要将系统暴露给用户，也不要责怪用户的行为。
一个好的错误信息应该包含：
- 问题是什么，为什么发生。
- 如何解决问题。
你可以做的最糟糕的事情之一就是将系统错误消息传递给用户。 例如，当您的Java程序引发exception时，不要简单地将程序员传递给UI，并将其暴露给用户。 抓住它，并有一个清晰的信息，由您的用户协助开发人员，您可以提供给您的用户。
在我上一份工作中，我很幸运能够和一个不想写自己的错误信息的程序员一起工作。 任何时候，他们发现自己处于一个需要的地方，程序不能被devise为避免（通常是因为资源有限），他们总是来找我，解释他们需要什么，让我创build一个错误信息，清晰，遵循公司风格。 如果这是每个程序员的默认思维模式，计算世界将是一个更好的地方。
更less的错误
如果一个应用程序会定期向你吐吐，你就会免疫，并且错误会变成恼人的背景muzak。 如果一个错误是一个罕见的事件，它将获得更多的关注。
反问任何不重要的事情，抛弃所有的警告，find理解用户意图的方法，尽可能地去做出决定。 我有几个应用程序，我继续这样简化。 开发人员将每个错误视为重要，但从用户的angular度来看这不是事实。 寻找用户对问题的共同回应，并捕获问题，并将其作为您的回应进行部署。
如果你确实需要提出一个错误：简短，简洁，低的恐怖因素，没有感叹号。 段落失败 。
没有银弹，但是你需要社交工程师来使错误变得重要。
我们告诉用户他们的经理已经联系了（这是一个谎言）。 它工作得太好了，不得不被删除。
添加一个“高级”button，使更多的技术细节，将提供一个激励，阅读它的部分目标受众，认为自己的技术
我build议你在发现错误后立即给出反馈（说明用户犯了错误）。 （例如，inputdate字段的值时，请检查该值，如果错误，则使input字段在视觉上不同）。
如果页面上有错误（我更多的是网页开发，所以我把它称为“页面”，但也可以称为“窗体”），显示“错误摘要”，解释那里是错误和错误列表，究竟发生了什么错误。 但是，如果每封邮件的字数超过5至6个，则不会被读取/理解。
如何使button状态“点击这里与支持技术人员谁将会帮助你解决这个问题。
有许多网站提供与真人对话的选项。
我读了一个关于slashdot最可怕的解决scheme的候选人：
我们发现让用户对错误负责的唯一方法就是让错误消失。 对于初学者来说，在可能的情况下，除非我们inputpipe理员密码使其消失，否则错误将不会实际closures，如果他们重新启动以排除此错误（所有客户端计算机上的任务pipe理器都被禁用），计算机将无法打开应用程序崩溃了15分钟。 当然，这一切都取决于你正在处理的用户types，因为更多的技术熟练的用户不会接受这种系统，但在尝试从字面上的年份，让用户负责崩溃，并确保IT部门了解他们为了解决这个难题之前难以pipe理的问题，这些是唯一的工作步骤。 现在，我们所有的最终用户都知道，如果他们忽视错误，他们自己就会受苦。
“注意！注意！如果你不读错误信息，你会死！
尽pipe接受的答案中有所有的build议，我的用户继续点击他们可以find的第一个button。 所以现在我展示这个：
用户必须在OKbutton出现之前做出select
如果他select第三个选项，他可以继续，否则应用程序退出。
