如何让用户关注问题？
我们有时需要通知用户有关警告或问题。 但很多时候，特别是如果这是一个常见问题，用户会忽略警告并继续。 很多时候，用户甚至不记得看到过警告，但我们检查他们的日志，发现显示了几个警告。 那么，当您试图告诉用户一些重要的事情时，如何让用户注意呢？
这并不像强迫用户在允许他们保存之前解决所有问题那么简单。 由于各种原因（通常是无法立即解决或根本无法解决的问题），他们经常需要保存我们的业务规则严格不允许的数据。
我们已经有了一个更好的警告/错误处理系统，我认为这会有很大帮助，但我想看看其他人做了什么。
We occasionally need to notify users about warnings or problems. But often times, especially if it's a common problem, users will just dismiss the warning and continue. Often times users won't even remember seeing the warning, but we check their logs and see that several were displayed. So, how do you get users to pay attention when you're trying to tell them something important?
This isn't as simple as forcing users to resolve all problems before allowing them to save. They often need to save data that isn't strictly okay by our business rules for various reasons (usually for problems that can't be solved right away, or at all).
We've got a better warning/error handling system in mind that I think will help a lot, but I want to see what others have done.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
这就是我们所计划的。 本质上，创建一些类似 Bugzilla 的东西来存储这些错误/警告/其他内容。 但它也与其他一些答案密切相关。
不使用简单的 MessageBox，而是在类似 Visual Studio 的错误窗口中显示警告/错误。 只要有问题，就会显示在这个窗口中。
如果保存数据，则将所有警告/错误保存到数据库中。 现在任何人都可以看到当前的问题是什么 - 奖金！ 此外，这些问题可以从数据库加载，而不是一直在应用程序中检测它们，这将有很大帮助 - 有些问题检测起来并不容易。
允许用户执行多项操作，例如：
将所有这些操作记录到数据库中，以便我们有责任，
简而言之就是这样。 现在问题仍然存在，因此它们一直摆在用户面前，直到解决为止。 这些问题是可以追踪的，所以如果我们被咬了，我们可以知道球落在哪里。 我希望它有效！
This is what we've got planned. Essentially, create something Bugzilla-ish for storing these errors/warnings/whatever. But it also goes hand in hand with some of the other answers.
Instead of using simple MessageBox, display warnings/errors in a Visual Studio-like error window. As long as there are problems, they'll be displayed in this window.
If the data is saved, save all warnings/errors to the database. Now anyone can see what the current issues are - bonus! Also, those problems can be loaded from the database instead of detecting them in the app all the time, which will help a lot - some problems are not trivial to detect.
Allow users to perform several actions, like:
Log all of these actions to the database, so we have accountability
That's it in a nutshell. Now problems stick around, so they're in the users faces until they're solved. The problems can be tracked, so we can tell where the ball was dropped if we get bit. I hope it works!
尽管我从未在以前的站点上实现过这一点，但我想创建一个自定义对话框，用户必须在其中选中一个框，表明他们已阅读并确认该消息（然后记录该响应）。 这是一家 ISO-xxxx 公司，因此这种官僚主义是对此类错误的合乎逻辑的反应。
我的另一个更险恶的想法是将“否”或“取消”设置为默认选项。 最终他们会按下 Tab-Enter 按键，然后你只需将其切换回来即可。
Though I never got around to implementing this at a previous site, I wanted to create a custom dialog box where users would have to check a box stating that they have read and acknowledged the message (and then log that response). This was for an ISO-xxxx company so this kind of bureaucracy was a logical response to these types of mistakes.
My other, much more sinister, idea was to make "No" or "Cancel" the default options. Eventually they would get the Tab-Enter keystrokes down pat and then you would just switch it back.
破坏系统！
老实说，根据我的经验，如果您不希望最终用户在没有明确理解的情况下做某事，请阻止他们这样做......
尽管整个“Windows 错误/警告消息”非常烦人，但我从不接受注意，直到程序告诉我我不能做某事...然后我被迫问自己“为什么不”
是时候用谷歌搜索答案...或 RTFM
我知道使用这种方法并不总是可行，但是如果可以的话...他们会听的！
Break the system!
It has honestly been my experience that if you don't want an end user to do something without explicitly understanding it, stop them from doing it...
As seriously anoying as the whole "Windows Error/warning Messages" gets, I never take notice until a program tells me I can't do something... then I am forced to ask myself "Why Not"
Time to google the answer... or RTFM
I know that it is not always feasible to use this approach, but if you can... they will listen!
我喜欢那些暗示存在问题的程序，同时尽可能长时间地忽略它——这听起来很像你正在努力的目标。 我一直在考虑的一件事（但含糊不清，因为我还没有使用过它）是为错误/警告放置一个状态指示器（有点像网络浏览器的无所不在的颤动器，但用于错误）。 该图标会改变状态，有点像交通灯，以表明程序存在迟早必须解决的问题 - 如果数据问题可以稍后纠正并且不会出现，则可能会显示黄色警告导致任何重大问题，红色表示在完成当前作业之前必须解决的任何问题（对于表单数据，这意味着整个事务，而不是当前表单）。 显然，光有颜色是不够的，还必须为色盲人士提供一些支持，但你明白了。 单击该指示器将显示问题列表（也许还可以解释为什么这是一个问题 - 以便人们可以指出代码的假设何时无用或错误），然后选择一个问题将允许您跳转到可以修复它的字段。
无论您最终采用哪种方法，您可能应该做的一件事就是仔细检查您的警告并确定它们是否确实有必要。 我见过太多的程序警告我有关随后接受的完全合理的输入，或者警告我有关程序的通常行为。 这就是帮助人们点击警告的原因。 如果您有警告日志，您可能会从这里开始 - 为什么人们点击它们？ 它们可能是有条件的，或者可能确实没有问题，而有人没有告诉你事情已经发生了变化。
I like programs that hint that there's a problem while ignoring it as long as possible - which sounds very like what you're striving for. One thing I've been thinking about (but vaguely, since I haven't had a use for it) is putting a status indicator for errors/warnings (a bit like the omnipresent throbber of a web-browser, but for errors). This icon would change state, a bit like a traffic light, to show that the program has problems that will have to be addressed sooner or later - perhaps yellow for warnings if the problem with the data could be corrected later and isn't going to cause any major problems, red for any problem that is going to have to be fixed before they complete the current job (for form data, that would mean the whole transaction, not the current form). Obviously the colours wouldn't be enough, there would have to be some support for colour-blind people, but you get the idea. Clicking the indicator would bring up a list of the problems (and perhaps explanations as to why that is a problem - so that people can point out when the code's assumptions are unhelpful or wrong), and selecting a problem would allow you to jump to the field where it can be fixed.
One thing you should probably do, whatever method you go with in the end, is to look through your warnings and work out whether they're actually necessary. I've seen far too many programs that warn me about perfectly reasonable input that is then accepted, or warn me about the usual behaviour of the program. That's the sort of thing that helps condition people to click through warnings. If you have logs of the warnings, you might start there - Why are people clicking through them? They might be conditioned, or it might be that there genuinely isn't a problem, and someone hasn't told you that things have changed.
我很喜欢firefox安装插件的方法：ok按钮被禁用，并显示5秒倒计时。 之后用户可以选择忽略它。
I quite like the firefox method when installing plugins: The ok button is disabled and displays a countdown for 5 seconds. After that the use can choose to ignore it.
对于 Web 应用程序，alert() 和 inform() javascript 方法虽然有些基本，但可以达到阻止用户执行某些操作或确保他们明确同意他们被警告的某些操作的效果。
对于其他情况，如果该操作不会对业务流程造成严重干扰，我们通常会在提交表单后（例如提交表单）在页面顶部显示一个小警告框。
例如，我们的应用程序需要在多个地方进行位置验证（有效的城市/州/邮政编码）。
如果位置绝对重要，我们将在表单上将其设为必填。
如果应用程序的某些方面需要该位置，我们将使用confirm()来确保他们了解，如果没有有效的位置，他们将无法使用某些功能。
在某些情况下，我们使用默认位置。 在这种情况下，我们会在下一页的顶部提供消息/警告框，指示正在使用默认位置。
For web applications, the alert() and confirm() javascript methods, while somewhat basic, achieve the effect of either preventing users from doing something or making sure that they clearly agree to something that they have been warned about.
For other situations, where the action will not cause considerable disruption in the business processes, we often display a small warning box at the top of the page after, say, a form is submitted.
For example, our applications require location validation in several places (valid city/state/zip).
If the location is absolutely critical, we will make it required on the form.
If the location is required for some aspects of the application, we will use the confirm() to make sure they understand that they will not be able to use certain features without a valid location.
In some cases, we use a default location. In that case, we provide the message/warning box at the top of the next page indicating that a default location is being used.
我发现，如果您生成供自己使用的日志消息（即使这种使用直接使用户本身受益），那么让用户报告问题的唯一方法就是让应用程序为他们做这件事。
在处理可能错误的用户输入的情况下，您是否考虑过使用诸如拼写检查所使用的红色波浪线之类的东西，或者在用户工作时对问题区域进行某种突出显示？ 大多数用户都接受过使用有缺陷的软件来忽略对话框的培训，但这种消息可能会明确表明该错误需要用户修复。
I've found that if you're producing log messages for your own use (even if that use directly benefits the users themselves), the only way to get users to report problems is to have the application do it for them.
In the case of dealing with user input that might be wrong, have you considered using something like the red squigglies used by spell checking or some kind of highlighting of the problem areas as the user does their work? Most users have been trained to ignore dialogs by using buggy software, but that kind of message might make it clear that the error is the user's to fix.
您清楚为什么每种异常情况会发生吗？ 您尝试通过这些消息实现什么目的：
让用户检查数据是否存在明显的拼写错误或错误
让其他人检查数据稍后阶段，当有更多信息可用时
通知该用户以及稍后阶段查看数据的任何其他人所做的任何假设< /p>
确保用户了解其行为的后果
这些中的任何一个都可以以不同的方式更有效地实现目标？
一些想法（它们都不会自动成为灵丹妙药）：
保持消息简短且相关，排除任何不提供额外信息的语言（例如“请”等），告诉用户对他们的期望（即使用“输入邮政编码”而不是“邮政编码为空”。）。
使用用户可以理解的语言，始终提供足够的信息，尽量具体。
使用
对不同类型的警告和错误使用不同的消息（使用字体、颜色、图像，可能还有动画和声音）。
对
重新访问整个流程，以便有人必须稍后处理任何提交的带有警告的信息。
重新访问整个流程
下次信息显示在屏幕上时，可视化警告（即突出显示有问题的区域），以便稍后在有更多信息可用时解决这些问题。
在警告中添加签名，例如，在每次需要消除警告时请求用户输入密码。
使操作可撤消，因此您实际上不需要警告
Do you have a good idea why each of the exceptional situations occurs? What do you try to achieve with each of these messages:
make user review the data for obvious typos or mistakes
make someone else to review the data at a later stage when more information is available
inform this user and anyone else looking at the data at a later stage about any assumptions made
make sure user understands the consequences of their actions
Can any of these goals be achieved more effectively in a different way?
Some ideas (none of them automatically qualify as a silver bullet):
Keep messages short and relevant, exclude any language that does not contribute additional info (such as "please" etc), tell users what is expected of them (i.e. instead of "Post code is empty" use "Enter post code".).
Use language that is understood by the users, always give sufficient information, try to be as specific as possible.
Use different looking messages for different types of warnings and errors (use font, colour, imaging, possibly animation and sound).
Revisit the entire process, so that someone has to process any info submitted with warnings later on.
Visualise warnings the next time info brought to the screen (i.e. highlight problematic areas) so that they can be resolved later, when more info is available.
Add a sign off to the warnings, for instance request a user to enter their password each time they need to dismiss a warning.
Make actions undo-able, so you don't really need the warnings
不要尝试通过编程来解决。 看看是否可以改变数据输入过程。
Dont try to solve with programming. See if you can change the data input process.
使用颜色和图标。
绿色 - 一切正常（或确认某些事情按预期发生）
黄色 - 警告。 您的用户可能想也可能不想调查问题
红色 - 错误。 需要用户交互才能解决的问题。
我还建议（正如其他人在该线程上所做的那样）谨慎使用。
Use colors and icons.
Green - everything is ok (or confirmation something happened as expected)
Yellow - Warning. You user may or may not want to look into the issue
Red - Error. Something that requires user interaction to resolve.
I would also suggest (as others have on this thread) to use sparingly.
如果您希望用户注意警告，请适度使用它们！
Vista 中 UAC 的一个大问题是，人们收到太多通知，以至于他们不再了解谁正在请求访问什么，他们只是不假思索地给予许可。
另一个例子是将文件发送到回收站时在资源管理器中的删除确认。 我已经习惯了在按“删除”后立即点击“确定”，以至于我错过了这样一个事实：该对话框告诉我该文件不会被移动到垃圾箱，而是会立即删除，无论出于何种原因。
我的个人修复：我禁用了回收站的删除确认。 如果有些东西无法移至垃圾箱，我仍然会收到一条消息，这次我知道它可能很重要，所以我会注意。
结论：不要向用户发送垃圾邮件，否则重要的警告会淹没在噪音中。
If you want users to pay attention to warnings, use them in moderation!
The big problem with the UAC in Vista is that people are getting so many notifications, that they stop reading who is exactly requesting access to what, they just give permission without thinking.
Another example is the delete confirmation in explorer when sending files to the recycle bin. I got so used to just hitting 'Ok' immediately after pressing 'delete', that I missed the fact that the dialog was telling me that the file would not be moved to the bin, but deleted immediately, for whatever reason.
My personal fix: I disabled the delete confirmation for the recycle bin. If something can not be moved to the bin, I still get a message, and this time I know that it might be important, so I pay attention.
Conclusion: Don't spam the user with messages, or the important warnings will get lost in the noise.
您的警告质量不会阻止用户提交无效数据。 如果您允许提交无效数据，那就会发生。
如果您有必须提交给规则系统的数据，那么该数据在提交之前必须有效。 然而，允许用户保存他们的工作是一个单独的问题。 您应该允许用户保存他们的工作，然后在数据有效时将数据提交到规则引擎。
The quality of your warning will not prevent users from submitting invalid data. If you allow invalid data to be submitted, it will be.
If you have data that must be submitted to a rules system, then that data must be valid before it is submitted. However, allowing users to save their work is a separate issue. You should allow users to save their work, then submit the data to the rules engine when it is valid.
根本问题是用户不喜欢阅读，他们只想独自完成工作:)。
解决这个问题的最佳方法如下：
长的错误/警告消息根本不会被阅读。 用户将看到大约第五个单词并认为“这花费了太多时间，我只想回去工作”。
The fundamental problem is that users don't like to read, they just want to be left alone to do their work :).
The best way to combat this is the following:
Long error/warning messages simply won't get read. The user will get to about the fifth word and think "this is taking too much time, I just want to get back to work".
我的建议可以归结为三件事。
如果您的表单包含所需数据，则将该字段用颜色编码为红色或用星号突出显示以表明它是必需的。 禁用“确定”或“确认”按钮，直到填写所有必填字段。
对于数据不完整或不一致的字段，请显示工具提示或对字段进行颜色编码，以便用户知道可能出现问题。 您还可以在表单的显着位置显示警告列表。 但不要停止数据输入。 你只会让你的用户感到沮丧和愤怒。
My advice boils down to three things.
If you have a form with required data, then color-code the field as red or highlight it with an asterisk to indicate it's required. Disable the "OK" or "Confirm" button until they fill out all required fields.
For fields with incomplete or inconsistent data, bring up a tooltip or color-code the field so the user knows that something may be wrong. You could also display the list of warnings prominently somewhere on your form. But don't stop the data entry. You'll just frustrate and anger your users.
我必须承认，我经常点击“确定”或任何我习惯做的事情，对话框就会不假思索地消失。 通常，当它们太多时，就会发生这种情况。
在不自称是任何类型的心理学家的情况下，我认为关注不寻常的事物并过滤掉重复的事物是很自然的。
考虑到这一点，也许值得考虑减少不太重要的对话的干扰，以便真正重要的对话得到更多关注。
我认为烤面包机消息和谷歌在其在线应用程序中处理消息的方式是如何通知用户一些无关紧要的事情的真正很好的例子。
--编辑--
现在我重新阅读我的帖子，我记得在“别让我思考”中读过这篇文章。
一本精彩的小书（几十页），充满了美好且易于理解的可用性内容。 有点注重在线可用性，但实际上也适用于离线应用程序。
I must admit that I too often click on "OK" or whatever I'm conditioned to do for a dialog to go away without thinking. Usually this occurs when there are just too many of them.
Without claiming to be a psychologist of any kind, I think it is natural to pay attention to unusual things and filter away repetetive things.
With that in mind it is maybe worth considering to make less important dialogues less intrusive so that the real important ones get more attention.
I think toaster messages and the way google handles messages in it's online apps are real nice examples of how to notifiy a user of something inessential.
--EDIT--
Now that I re-read my post, I remember reading this in "Don't Make Me Think".
A brilliant little book (few tens of pages) that's full of nice and easy to understand usability things. Somewhat focused on online usability, but defenatly applyable in offline applications too.