We are three internal developers with a user count of about twenty. We've implemented unhandled exception handling in our Winforms app. It generates a ticket with the stack trace in our FogBugz (renamed internally to DevTracker) bug tracking system.
我们是三个内部开发人员，用户数量约为20人。我们在Winforms应用中实现了未处理的异常处理。
The goal is to encourage the user to enter an informative bug rather than simply moving on. When they click the first button we do the work to put them on our project site with a new case started. They simply have to fill in the comment box. I'm debating whether or not the "What are we doing?" section should exist.
我们的目标是鼓励用户输入信息性的错误，而不是简单地继续。当他们点击第一个按钮时，我们做的工作是把他们放在我们的项目网站，一个新的案例开始。他们只需要填写评论框。我在争论“我们在做什么”这一节是否应该存在。
What's your opinion?
你的意见是什么?
http://thegollys.smugmug.com/photos/555553239_LxEPK-S.jpg
http://thegollys.smugmug.com/photos/555553239_LxEPK-S.jpg
Take two
取两个
A little more background... The users are well versed in using FogBugz (Dev Tracker) as it's how they request feature and bug fixes currently. In addition to unhandled error handling, we've added log4net into the mix for the next release. It pushes the stack trace to a log on the users local machine (in case of a down network), an internal database, and a FogBugz case.
更多的背景……用户非常熟悉使用FogBugz (Dev Tracker)，因为这是他们当前请求特性和bug修复的方式。除了未处理的错误处理之外，我们还为下一个版本添加了log4net。它将堆栈跟踪推到用户本地机器上的日志(如果是下行网络)、内部数据库和FogBugz案例。
After reading Andrew's answer it pushed me towards what I was already thinking... simpler is always better. I've removed the "What we're doing" section all together and paired down the verbiage. http://www.thegollys.com/photos/555771972_VUTxK-S.jpg
读了安德鲁的回答后，我开始思考……简单越好。我把“我们在做什么”这一节都去掉了，把它们分成两部分。http://www.thegollys.com/photos/555771972_VUTxK-S.jpg
Take three
花三
Thanks for all the feedback. This is what we're implementing. http://thegollys.smugmug.com/photos/558265081_5sPG2-O.jpg
谢谢大家的反馈。这就是我们要实现的。http://thegollys.smugmug.com/photos/558265081_5sPG2-O.jpg
4 个解决方案
#1
2
Users hate it when they're trying to get something done and you interrupt them. (I know, I'm one of them.) And here, you're not even giving them the chance to pick the default answer. I totally understand why, but tread carefully. Interrupt their train of thought as little as you can possibly get away with.
当用户试图完成某件事而你打断了他们时，他们会很讨厌。(我知道，我也是其中之一。)这里，你甚至没有给他们选择默认答案的机会。我完全理解个中缘由，但我得小心行事。尽可能少地打断他们的思路。
(By the way, after this, does the app terminate, or do you recover and let them continue with what they were doing?)
(顺便问一下，在此之后，应用程序会终止吗?还是你会恢复并让他们继续他们正在做的事情?)
So you're giving the user two options: "tell us what you were doing" and "get on with it" (but with way more words than that on the button, even in Take Two). You really want them to pick "tell us what you were doing", but as I understand it, you implement it by opening a Web browser. Huge interruption. Once the user is done, they'll have totally forgotten where they left off. They'll also hate you and won't give you useful comments. (Heck, by the time the browser finishes loading, they're likely to have gotten distracted by another app (or by restarting your app), and leave the Web page "for later", by which time they've forgotten any useful context.)
所以你给了用户两个选项:“告诉我们你在做什么”和“继续做下去”(但是按钮上的单词要比这个多，即使是两个)。你真的想让他们选择“告诉我们你在做什么”，但正如我所理解的，你是通过打开Web浏览器来实现的。巨大的中断。一旦用户完成了，他们就会完全忘记自己的位置，他们也会讨厌你，不会给你有用的评论。(在浏览器完成加载的时候，他们可能会被另一款应用程序分心(或者重新启动你的应用程序)，然后把网页“留到以后”，在这段时间里，他们忘记了任何有用的内容。)
Instead, why not put a text box right there in the dialog? Might be a little more work for you to wire up initially, but I think you'd get better feedback.
相反，为什么不在对话框中设置一个文本框呢?一开始你可能需要做更多的工作，但是我认为你会得到更好的反馈。
I'm thinking something like this:
我是这么想的:
http://www.excastle.com/misc/so958196.png
http://www.excastle.com/misc/so958196.png
- Excuse courtesy of the "The Bastard Operator From Hell"-style excuse server. They have more.
- “地狱里的私生子”式的借口服务器。他们有更多的。
- Start with the cursor in the "Tell us what you were just doing" text box, so it's easy for them to give you feedback: just a matter of typing something and hitting Enter (or clicking the button with only three words on it).
- 从“告诉我们你在做什么”文本框中的光标开始，这样他们就很容易给你反馈:只需输入一些东西并点击回车(或者点击上面只有三个字的按钮)。
- Make "Finish crashing already" a hyperlink, so it's there but de-emphasized. Left-justify it so people don't immediately associate it with the Cancel button it really is.
- 让“完成崩溃已经”成为一个超链接，所以它是存在的但是没有强调。左对齐，这样人们就不会马上把它和取消按钮联系起来。
- If someone does fill in the box and submit a bug report, your "hey, thanks!" dialog could mention "by the way, if you get this again, you can click the 'I've reported this before' hyperlink", and show a screenshot with a red circle and arrow so they maybe notice.
- 如果有人填了这个框并提交了一个bug报告，你的“嘿，谢谢!”对话框可能会提到“顺便说一下，如果你再收到这个，你可以点击“我在超链接之前报告过这个”，然后显示一个带有红色圆圈和箭头的屏幕截图，这样他们可能会注意到。
- Any other text you want can go in a sidebar with a different background color. Banner-ad blindness will keep people from even seeing it unless they're in a curious (and patient) mood.
- 你想要的任何其他文本都可以在侧边栏中使用不同的背景颜色。除非是出于好奇(和耐心)的情绪，否则，“Banner-ad失明”会让人们不去看它。
#2
1
The approach I've taken is to make it as simple as possible for the user. They're already worried about the fact that you're presenting them with a scary looking error message, so you don't want to introduce extra stress by interrogating them. Ask for a brief comment and pick up as much as you possibly can automatically.
我采用的方法是让用户尽可能地简单。他们已经在担心你给他们呈现一个可怕的错误信息，所以你不想通过询问他们来增加额外的压力。问一个简短的评论，然后尽可能地自动回复。
It's worth noting that with FogBugz you can store a message against a case once you've diagnosed it. If the same error occurs again you can get that message back from the server to present to users. I've moved away from FogBugz over the last few years so my memory on exactly how that works is a little fuzzy, but I do recall being able to store a corrective action message and present that to users when it made sense.
值得注意的是，在FogBugz中，一旦你诊断出了一个病例，你就可以存储一个针对这个病例的信息。如果同样的错误再次发生，您可以从服务器获取该消息以呈现给用户。在过去的几年里，我已经远离了FogBugz，所以我对它是如何工作的记忆有点模糊，但我确实记得我能够存储一个正确的动作信息并在有意义的时候将它呈现给用户。
EDIT: Now that I've seen the image my comments still stand. Simplify and take away any scary language. I'd remove references to "Dev team"; use "us" instead. Remove references to "normal English". You want to ask simple questions: "What were you doing?".
编辑:现在我看到了这张照片，我的评论仍然站得住脚。简化并删除任何可怕的语言。我将删除对“开发团队”的引用;使用“我们”。删除对“正常英语”的引用。你想问一些简单的问题:“你在做什么?”
#3
0
I don't know if you're already doing this behind the scenes, but I like the approach of simply allowing the user to enter their email address and click "Send Error Report".
我不知道你是否已经在幕后这么做了，但是我喜欢这种简单的方法，允许用户输入他们的电子邮件地址并点击“发送错误报告”。
And then when I get the error details I'll look into the problem, fix it, and then immediately reply to them letting them know the issue is resolved.
当我得到错误细节时，我将检查问题，修复它，然后立即回复他们，让他们知道问题已经解决。
This does a couple of things. It makes it extremely easy for the user to submit the error along with a way for them to be notified when it's resolved. And it lights a fire under my butt to get the issues resolved as soon as possible so I don't get the same error report from dozens of users.
这有一些作用。它使用户能够非常容易地提交错误，以及在解决错误时通知他们的方法。它点燃了我的火焰，使问题尽快得到解决，所以我不会从几十个用户那里得到同样的错误报告。
Of course, when I've implemented this method its been for websites, not desktop applications. And they're sites that I'm able to make changes to very quickly.
当然，当我实现这个方法时，它是针对网站而不是桌面应用程序的。它们是我能够快速改变的网站。
#4
0
We have something similar (not quite so weird -- kudos to you), but we also have the ability to view the exception (hidden from user by default of course) for developers that may be troubleshooting at a user location or for users that are calling the help desk.
我们有一些类似的东西(不太奇怪——值得称赞)，但是我们也有能力查看异常(默认情况下是对用户隐藏的)，对于可能正在用户位置进行故障排除的开发人员或正在调用帮助台的用户。
Also, you could tell them that you are going to send the guy to the right in the picture to their desk to help them if they don't submit the report. That should scare them into doing it. :)
另外，你可以告诉他们，如果他们不提交报告，你将把图片右边的人送到他们的办公桌上帮助他们。这会吓到他们去做这件事。:)
#1
2
Users hate it when they're trying to get something done and you interrupt them. (I know, I'm one of them.) And here, you're not even giving them the chance to pick the default answer. I totally understand why, but tread carefully. Interrupt their train of thought as little as you can possibly get away with.
当用户试图完成某件事而你打断了他们时，他们会很讨厌。(我知道，我也是其中之一。)这里，你甚至没有给他们选择默认答案的机会。我完全理解个中缘由，但我得小心行事。尽可能少地打断他们的思路。
(By the way, after this, does the app terminate, or do you recover and let them continue with what they were doing?)
(顺便问一下，在此之后，应用程序会终止吗?还是你会恢复并让他们继续他们正在做的事情?)
So you're giving the user two options: "tell us what you were doing" and "get on with it" (but with way more words than that on the button, even in Take Two). You really want them to pick "tell us what you were doing", but as I understand it, you implement it by opening a Web browser. Huge interruption. Once the user is done, they'll have totally forgotten where they left off. They'll also hate you and won't give you useful comments. (Heck, by the time the browser finishes loading, they're likely to have gotten distracted by another app (or by restarting your app), and leave the Web page "for later", by which time they've forgotten any useful context.)
所以你给了用户两个选项:“告诉我们你在做什么”和“继续做下去”(但是按钮上的单词要比这个多，即使是两个)。你真的想让他们选择“告诉我们你在做什么”，但正如我所理解的，你是通过打开Web浏览器来实现的。巨大的中断。一旦用户完成了，他们就会完全忘记自己的位置，他们也会讨厌你，不会给你有用的评论。(在浏览器完成加载的时候，他们可能会被另一款应用程序分心(或者重新启动你的应用程序)，然后把网页“留到以后”，在这段时间里，他们忘记了任何有用的内容。)
Instead, why not put a text box right there in the dialog? Might be a little more work for you to wire up initially, but I think you'd get better feedback.
相反，为什么不在对话框中设置一个文本框呢?一开始你可能需要做更多的工作，但是我认为你会得到更好的反馈。
I'm thinking something like this:
我是这么想的:
http://www.excastle.com/misc/so958196.png
http://www.excastle.com/misc/so958196.png
- Excuse courtesy of the "The Bastard Operator From Hell"-style excuse server. They have more.
- “地狱里的私生子”式的借口服务器。他们有更多的。
- Start with the cursor in the "Tell us what you were just doing" text box, so it's easy for them to give you feedback: just a matter of typing something and hitting Enter (or clicking the button with only three words on it).
- 从“告诉我们你在做什么”文本框中的光标开始，这样他们就很容易给你反馈:只需输入一些东西并点击回车(或者点击上面只有三个字的按钮)。
- Make "Finish crashing already" a hyperlink, so it's there but de-emphasized. Left-justify it so people don't immediately associate it with the Cancel button it really is.
- 让“完成崩溃已经”成为一个超链接，所以它是存在的但是没有强调。左对齐，这样人们就不会马上把它和取消按钮联系起来。
- If someone does fill in the box and submit a bug report, your "hey, thanks!" dialog could mention "by the way, if you get this again, you can click the 'I've reported this before' hyperlink", and show a screenshot with a red circle and arrow so they maybe notice.
- 如果有人填了这个框并提交了一个bug报告，你的“嘿，谢谢!”对话框可能会提到“顺便说一下，如果你再收到这个，你可以点击“我在超链接之前报告过这个”，然后显示一个带有红色圆圈和箭头的屏幕截图，这样他们可能会注意到。
- Any other text you want can go in a sidebar with a different background color. Banner-ad blindness will keep people from even seeing it unless they're in a curious (and patient) mood.
- 你想要的任何其他文本都可以在侧边栏中使用不同的背景颜色。除非是出于好奇(和耐心)的情绪，否则，“Banner-ad失明”会让人们不去看它。
#2
1
The approach I've taken is to make it as simple as possible for the user. They're already worried about the fact that you're presenting them with a scary looking error message, so you don't want to introduce extra stress by interrogating them. Ask for a brief comment and pick up as much as you possibly can automatically.
我采用的方法是让用户尽可能地简单。他们已经在担心你给他们呈现一个可怕的错误信息，所以你不想通过询问他们来增加额外的压力。问一个简短的评论，然后尽可能地自动回复。
It's worth noting that with FogBugz you can store a message against a case once you've diagnosed it. If the same error occurs again you can get that message back from the server to present to users. I've moved away from FogBugz over the last few years so my memory on exactly how that works is a little fuzzy, but I do recall being able to store a corrective action message and present that to users when it made sense.
值得注意的是，在FogBugz中，一旦你诊断出了一个病例，你就可以存储一个针对这个病例的信息。如果同样的错误再次发生，您可以从服务器获取该消息以呈现给用户。在过去的几年里，我已经远离了FogBugz，所以我对它是如何工作的记忆有点模糊，但我确实记得我能够存储一个正确的动作信息并在有意义的时候将它呈现给用户。
EDIT: Now that I've seen the image my comments still stand. Simplify and take away any scary language. I'd remove references to "Dev team"; use "us" instead. Remove references to "normal English". You want to ask simple questions: "What were you doing?".
编辑:现在我看到了这张照片，我的评论仍然站得住脚。简化并删除任何可怕的语言。我将删除对“开发团队”的引用;使用“我们”。删除对“正常英语”的引用。你想问一些简单的问题:“你在做什么?”
#3
0
I don't know if you're already doing this behind the scenes, but I like the approach of simply allowing the user to enter their email address and click "Send Error Report".
我不知道你是否已经在幕后这么做了，但是我喜欢这种简单的方法，允许用户输入他们的电子邮件地址并点击“发送错误报告”。
And then when I get the error details I'll look into the problem, fix it, and then immediately reply to them letting them know the issue is resolved.
当我得到错误细节时，我将检查问题，修复它，然后立即回复他们，让他们知道问题已经解决。
This does a couple of things. It makes it extremely easy for the user to submit the error along with a way for them to be notified when it's resolved. And it lights a fire under my butt to get the issues resolved as soon as possible so I don't get the same error report from dozens of users.
这有一些作用。它使用户能够非常容易地提交错误，以及在解决错误时通知他们的方法。它点燃了我的火焰，使问题尽快得到解决，所以我不会从几十个用户那里得到同样的错误报告。
Of course, when I've implemented this method its been for websites, not desktop applications. And they're sites that I'm able to make changes to very quickly.
当然，当我实现这个方法时，它是针对网站而不是桌面应用程序的。它们是我能够快速改变的网站。
#4
0
We have something similar (not quite so weird -- kudos to you), but we also have the ability to view the exception (hidden from user by default of course) for developers that may be troubleshooting at a user location or for users that are calling the help desk.
我们有一些类似的东西(不太奇怪——值得称赞)，但是我们也有能力查看异常(默认情况下是对用户隐藏的)，对于可能正在用户位置进行故障排除的开发人员或正在调用帮助台的用户。
Also, you could tell them that you are going to send the guy to the right in the picture to their desk to help them if they don't submit the report. That should scare them into doing it. :)
另外，你可以告诉他们，如果他们不提交报告，你将把图片右边的人送到他们的办公桌上帮助他们。这会吓到他们去做这件事。:)