Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In my app when an unhandled error occurs a popup window opens. It has a field to add additional info but it's optional. This is completely anonymous.

Due to security issues I cannot use a stack-trace to identify the exact line or code which resulted in the error. So, there is not much use from the error reported.

None of the users provide me with additional info, so my question is can I make it mandatory for the user to describe the error in his own words. Also, I plan adding an email field as an optional field, so that the user can still do it anonymously if needed.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

Yes you can, but it will not help you much.

What you need is information on what was happening when an exception was thrown in your code. In many cases, users can't even provide you the information you need, because they have no idea what is going on in the code. In other cases, they do have relevant information (e.g. what they were clicking when the error occurred), but 1) it is not their job to provide it, 2) it is very hard for them to do so (they have no idea of programming, so it is very hard for them to recognize which parts of their knowledge are relevant for you, and to find a formulation useful for you), and 3) your buggy application just interrupted their work flow with an error message. You violated their expectations and wasted their time. They are angry, and don't want to lose any more time and spend the high cognitive effort required for writing a meaningful error report for you. You have neither the right nor the technical means to make them do so.

For these reasons, you cannot make user reports the main source of the error context information you need. You can gently nudge the users willing to make error reports into making better quality error reports, but you have to live with the fact that for virtually all errors, you will get no information from the users. In the rare cases where you get a report, it will be a very nice bonus for you. But it is a bonus, and you can't rely on it to become your primary information source.

The first thing you should do, if you are not already doing so, is to implement user-friendly error notifications. There are guidelines for doing so, I generally use the Microsoft guidelines, the general principles in them are applicable across all platforms. You can certainly look around for other sources on how to create good error notifications. One important thing which will happen when you do so is that you will stop showing all unhandled exceptions to users. So, you have to take leave of the idea that the user will help you with all exceptions, he will only be able to help you with the ones you show to him. The rest will have to be logged and handled in some other way, e.g. you can set up a test environment where you can turn on stack traces.

You can certainly decide that, if a user wants to submit an error report, he also has to write an error description. This will mean that you will get very few error reports altogether, but the ones you do get will have a potentially useful description. Most users will still have no idea about the error, and no incentive to describe what they were doing when the error occurred, so they will choose to not write anything. If writing is mandatory for sending a report, they will choose to not send a report at all. I will only go this way if a report without user description is truly worthless.

You cannot make both sending a report and filling in some information mandatory. If you do this, you will anger many users to the point of giving up the use of your product and going to the competition. If they are not allowed to stop using your product (e.g. it is a product they have to use at work and the company management decides which product gets used), they will hate you and your system, give it a general bad reputation, and they will not provide you any usable information, probably starting write or paste nonsense into the mandatory text field. Not only will you have created a bad quality product, you will have to wade through error messages containing jokes, complaints, threats, and maybe even troll messages mimicking a real problem but not at all related to the actual situation in which the problem occurred. Users can be very creative in their destructive behavior when you work against them. There will be some more additional well-meant descriptions, but I doubt that much of them will be actually useful for you.

share|improve this answer
    
Thanks a lot for the inspiring answer :).I understand what you mean.The software is 95% error free.Almost all errors are handled.When a critical error occurs,out of the try catch stuff(rarely) when a user tries to do some combination of activities.From the error report i get,i can only get very little info.My question is if i present a comic or funny error report dialog(like some 404 pages do) and ask the user to tell what he/she was doing.will it be good. –  techno Dec 30 '13 at 13:47
    
Please see the updated question title 'mandatory' –  techno Dec 30 '13 at 13:49
    
It's hard to be done right. But if you manage it - hit the right tone, give them the necessary help so they understand exactly what information to give you, without having to read through long explanations first - you have a very good chance to get some more reports than what you are getting currently, and the reports to contain usable information. –  Rumi P. Dec 30 '13 at 13:50
    
Also instead of making,it mandatory.If a user does not enter the required description.A reconfirmation dialog appears saying how much the info will help us,if they want to rethink their decision.These users are FREE users ie: they got the app for free,this is where i get majority of error reports –  techno Dec 30 '13 at 13:53
add comment

You can make it mandatory, but ultimately you're at the mercy of what the user captured or can recall from the incident, or their willingness to provide feedback.

Capturing diagnostic logs/stack trace details automatically and transmitting to the developer is obviously the way to go for incidents, and eliminates the generic "Contact Support" approach. This can be done automatically or by choice (a nice Pebble watch feature by the way to launch an email app: http://help.getpebble.com/customer/portal/articles/1210316-contact-support ). However, you indicate that security prevents that.

Perhaps then you can guide the user to shape their feedback by use of selection lists - LOVs for example with lists of "what were you doing at the time", then a text box for descriptive content, and option to attach a screenshot, and then the means to send it to the development team.

It depends on the user profile too - their expertise in describing errors or failure or even wanting too.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.