验证码强制用户交互？
我目前正在开发一个程序，其中有很多“用户应该阅读它，但他会像愚蠢的猴子一样单击“确定””对话框......所以我正在考虑添加诸如验证码之类的东西以避免点击 -不假思索...
我的想法是：
- 随机更改按钮
- 将按钮随机放置在表单上的某处
- 用户必须单击他应该阅读的文本中的随机彩色单词
- 添加验证
- 码 添加包含用户消息的验证码
有没有人做过任何经验在这样的情况下。 你建议做什么？
I'm currently working on a program that has many of those "the user SHOULD read it but he'll click OK like a stupid monkey" dialogs... So I was thinking of adding something like a captcha in order to avoid click-without thinking...
My ideas were:
- Randomly change buttons
- Randomly position buttons somewhere on the form
- The user must click on a randomly colored word within the text he should read
- add captcha
- add captcha that includes the message for the user
Has anybody made any experience with such a situation. What would you suggest to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
好吧，您征求了意见，这是我的意见，但我认为这不是您想听到的……
用户喜欢他们可以依赖的程序。 他们不喜欢事情发生变化，也不喜欢做额外的工作。
随机更改按钮和随机放置按钮在表单上的某个位置只会使他们要么按错按钮，要么对您的应用程序感到恼火，因为正如您所说，他们不会阅读文本，如果您考虑一下，我们也不会。 举个例子，考虑一下“确定”/“取消”对话框，您总是希望“确定”按钮位于左侧，而大多数时候我会在不阅读它的情况下按下它。 您的用户也会发生完全相同的情况。
使用这 3 个选项，您将为您的应用程序添加额外的工作，您的用户会为此诅咒您。 想一想您每天必须执行 10 次的事情，比方说签入您的代码以保证源代码安全。 如果你的老板告诉你，从现在开始，你必须为你尝试签入的每个文件填写验证码，你会有什么感觉？
我认为我们的工作就是让使用我们软件的人们的生活变得更轻松。 如果他们必须阅读某种文本而他们又不愿意，那么你绝对没有办法让他们这样做。
你无法让人们正确工作，你所能做的就是为他们提供最好的工具，并希望他们足够专业来完成他们的工作。
所以基本上我想说的是，尽力减轻他们的工作压力。 如果这真的很重要，那么您（或任何负责人）应该与他们交谈并解释为什么这很重要。
你会对人们如何致力于他们理解的事情感到惊讶。
Well, you asked for opinions and here goes mine, but I don't think this is what you would like to hear...
Users like programs that they can depend on. They don't like when things change and they don't like to do extra work.
Randomly change buttons and Randomly position buttons somewhere on the form will only make them either press the wrong button or become annoyed with your application, because as you say, they don't read the text, and if you think about it, neither do we. As an example think of an Ok/Cancel dialog, you allways expect the ok button to be on the left, and most times i press it without reading it. It Will happen exactly the same with your users.
With these 3 option you will add extra work to your application, your users will curse you for that. Just think of something that you would have to do 10x per day, let's say check in your code to source safe. How would you feel if your boss told you that from now on you will have to fill a captcha for each file you try to check in?
I think it's our jobs to make the lives of the people that use our software easier. If they must read some kind of text and they don't want to, there is absolutely no way you can make them do it.
You can´t make people work right, all you can do is provide them with the best possible tools and hope that they are professional enough to do their jobs.
So basically all i'm saying is, do your best to ease their work. If this is really important than you(or whoever is in charge) should talk to them and EXPLAIN WHY this is important.
You would be surprised on how people commit to things they understand.
我建议你不要这样做； 并且，除非您更了解，否则您会模仿受人尊敬的知名且经过充分测试的 UI，例如大型在线零售商的 UI。 或<网上银行网站>。
I suggest that you don't; and that, unless you know better, you emulate respectable well-known, well-tested UIs like <big online retailer's> or <online banking site>.
为了让用户阅读消息而与用户玩游戏是注定要失败的。 用户将把精神资源集中在完成游戏上，而不是理解消息上。 如果您有移动按钮、重新标签、寻宝游戏、验证码或延迟等情况，您的用户可能不太真正理解消息的重要部分。 他们会关注游戏的说明，而不是真正的问题。 错误可能会增加。
用户拒绝阅读消息框是因为用户希望快速完成工作而不是花时间阅读内容，也是因为消息框在许多应用程序中被过度使用和滥用。 在消息框中添加愚蠢的游戏只会让用户更加反感它们，从而使问题更加复杂。
您可以执行以下操作：
规则 1. 不要使用消息框。 他们只应在特殊情况下出现。 应用程序不应该有“许多”消息框。 用户每次使用应用程序时都不需要阅读大量文档。 如果正常使用您的应用会出现消息框，则您的 UI 是错误的。 寻找另一种方式。
在主窗口中清楚地显示发生的情况，并提供明确的撤消方法，而不是验证消息。
使用自动更正、图片/屏蔽字段以及禁用而不是错误消息。
使用
使用良好的默认值和自动化来避免消息。 例如，不要显示一条错误消息，指出用户因未连接到服务器而无法上传，而只需自动重新连接即可。
沿选项中断命令。 在菜单中提供两个不同的命令，而不是通过消息框询问用户是否要带格式粘贴或不带格式粘贴。
不要自动弹出信息消息，告诉用户一切正常（例如，“首选项已保存！”）
没有弹出窗口提供有用的提示或文档。 如果您无法使 UI 自记录，请提供教程或气球帮助。
不要有烦人的“升级我”消息。
考虑在主窗口中而不是在单独的消息框中提供消息文本（例如，“由于出于安全考虑，ActiveX 已关闭，页面可能看起来或运行不正常。”）。 网上冲浪的弹出窗口使用户自动忽略任何不相关的弹出窗口。
规则 2. 如果您必须使用消息：
使文本尽可能简短，以传达关键信息。 更多文字并不等于更有帮助。 使用“与 [路径] 中的 [文件掩码] 不匹配。” 不要使用“非致命错误 307：搜索操作已中止。 [Appname] 无法完成对您提供的正则表达式的字符串搜索，因为您提供的文件掩码（即 [filemask]）不会在您指定的目录（即 [path]）中产生任何匹配的文件。 请检查您的文件掩码或路径选择，然后在“要搜索的文件”对话框中再次重新输入它们。 单击此消息框下方的“确定”按钮可返回“要搜索的文件”对话框。 当您到达“要搜索的文件”对话框时，单击“取消”按钮以取消对字符串的搜索。” 如果某些用户需要比简短消息更多的解释，请在消息框中提供“帮助”按钮或“我如何...”链接。
消息中使用简单的语言，不要使用行话。 其中包括“无辜”的词，如“对话框”、“数据库”和“墨粉”。 不要获取原始异常文本并将其放入错误消息中。 请勿包含任何错误号或转储； 而是记录这些。 清除应用程序中开发人员留下的任何调试消息框。 最好让应用程序因致命错误而消失，而不是发布一条充满行话的消息，然后应用程序就消失了。
用操作的作用来标记消息框的按钮，而不是“确定”。 至少，用户必须将注意力集中在激活按钮上才能关闭消息框。 如果该按钮标记为“删除”或“安装”之类的内容，则应该让他们暂停。 您不必在消息文本中解释每个按钮的用途。 顺便说一句，这种标签是大多数平台上的 GUI 标准。
Playing games with the user in order to get them to read messages is doomed. Users will focus mental resources on completing your game, rather than understanding the message. Your users may be less likely to actually understand the important part of the message if you have things like moved buttons, relabeling, scavenger hunts, captchas, or delays. They’ll focus on the instructions for the game, not on the real issue. Errors are likely to increase.
Users’ refusal to read message boxes is due to users wanting to get things done quickly rather than take the time to read stuff, and it is also due to message boxes being overused and misused so badly in so many apps. Including silly games in message boxes will just make users resent them all the more, compounding the problem.
Here’s what you can do:
Rule 1. Don’t use messages boxes. They should only appear for exceptional circumstances. An app should not have “many” message boxes. It should not be necessary to read a whole lot of documentation each time the user uses an app. If normal use of your app results in a message box, then your UI is wrong. Find another way.
Instead of verification messages, show clearly in the main window what has happened and provide a clear way to Undo it.
Use auto-correction, pictured/masked fields, and disabling rather than error messages.
Use good defaults and automation to avoid messages. For example, rather than showing an error message saying the user can’t upload because they’re not connected to the server, simply reconnect automatically.
Break commands along options. Rather that a message box to ask if the user wants paste with or without format, provide two different commands in the menu.
Don’t have information messages spontaneously popping up telling the user everything worked fine (e.g., “Preferences Saved!”)
Don’t have pop-ups providing helpful hints or documentation. Provide a tutorial or balloon help if you can’t make your UI self-documenting.
Don’t have nagging “upgrade me” messages.
Consider providing message text in the main window rather than in a separate message box (e.g., “Page may not look or act right because ActiveX is off for security.”). Pop-ups from web surfing have conditioned users to automatically dismiss anything that pops up as irrelevant.
Rule 2. If you have to use a message:
Make the text as brief as possible to get the key information across. More text is not equivalent to more helpful. Use “No match to [filemask] in [path].” Don’t use “Nonfatal Error 307: Search action aborted. [Appname] is unable to complete your string search for the regular expression you provided because the file mask you gave, namely [filemask], does not result in any matching files in the directory that you specified (which was [path]). Please check your filemask or path selection and again re-enter it or them in the Files to Search dialog box. Click the OK button below on this message box to return to the Files to Search dialog box. Click the Cancel Button on the Files to Search dialog when you get there to cancel your search for strings.” If there are some users who will need more explanation than can be achieved in a brief message, provide a Help button or a “How do I…” link in the message box.
Use plain language and no jargon in the message. That includes “innocent” words like “dialog,” “database,” and “toner.” Do not take raw exception text and throw it in a error message. Do not include any error numbers or dumps; log these instead. Purge your app of any debugging message boxes left by developers. Better to simply let the app disappear on a fatal error than to put up a message full of jargon and then the app disappears.
Label the buttons of a message box with what the action does, not “OK.” At the very least, the users have to focus on the activating button to dismiss a message box. If that button is labeled something like “Delete” or “Install,” it should give them pause. You should never have to explain in your message text what each button does. BTW, such labeling is a GUI standard on most platforms.
重新设计您的应用程序，使其不使用消息框。
Redesign your application so that it does not use message boxes.
我的建议是，接受它或重新设计你的对话框/界面。 不要不要向对话框添加随机性或以其他方式将用户视为白痴，即使您可能认为大多数人都是白痴:-)。
我最近刚刚读了一篇 Joel 关于软件的文章，为有更好事情要做的人设计他们的生活。 它表明大多数人不会阅读任何东西，并讨论了解决这个问题的方法，或者至少不会让情况变得更糟。
My suggestion, live with it or redesign your dialogs/interface. Do not add randomness to dialogs or otherwise treat the user like an idiot, even though you may think most are :-).
I just recently read a Joel on Software article, Designing for People Who Have Better Things To Do With Their Lives. It makes the point that most people won't read anything and discusses ways to work around that or at least not make it worse.
您可以尝试使用计时器，在启用提交按钮之前等待“假定的阅读时间”。 您甚至可以根据字数计算出假定的阅读时间。
我认为强迫用户阅读文本的微妙方式（例如移动按钮或要求他们阅读验证码）会让他们感觉像愚蠢的猴子。
You could try with a timer which waits for the "supposed reading time" before enabling the submit button. You can even calculate the supposed reading time from the number of words.
I think that subtle ways to force the user to read your text (like moving around buttons or asking them to read a captcha) can make them feel like stupid monkeys.
您可以根据用户应该阅读的内容使用选择问题。
You could use a choice question based on what the user should read.