16

I often have to deal with customers or users which are reporting errors in applications. Most of the time their content is something useless as

  • ERROR!!!
  • x does not work

without much more information.

For resolving the issue I have to request every single detail of them, which often is more time consuming than fixing the issue itself. Other send information in formats which are not ideal, like screenshots (of data records, not of errors) although they could send a link (we have access to the systems) and so on.

How do you tell your users/customers to describe the problems with more details so that the whole process could be easier for both sides?

edit

This question is more about the social skills, than how to achieve programmatic collection of logs and error information. I'm aware of the fact that this should be part of good software design.

ccellar
  • 263
  • 2
  • 9
  • 24
    You don't, you design your software to send error logs/messages to you. – Mahmoud Hossam May 04 '11 at 13:54
  • 8
    This unfortunately is not always possible particularly if you're supporting software which you did not develop, but which you bought in. – temptar May 04 '11 at 14:15
  • 1
    @Mahmoud: That's good advice, but it's really only relevant if you're at the design stage of a new app, or if you have the luxury (time and budget) of building such a feature into an existing appliation. – FrustratedWithFormsDesigner May 04 '11 at 14:20
  • 1
    "easier for both sides"? Both sides? They're already doing what's easiest for them. – S.Lott May 04 '11 at 14:28
  • @FrustratedWithFormsDesigner I know it's not possible most of the time, but it's the right thing to do. – Mahmoud Hossam May 04 '11 at 14:34
  • It's easy! Reply to the issue reporting emails that have poor information saying "This is not good enough, supply more information." You'll find your customers have far fewer issue to report. I think that's what's happened anyway... – Matt Ellen May 04 '11 at 15:00
  • use a logging framework like log4net or log4j! – Venki May 04 '11 at 15:43
  • @Mahmoud it's not possible when you control only a part of the software, because it is customized. – ccellar May 04 '11 at 19:57
  • @ckeller, have a small application which can take a screenshot and allow the user to set a mark at where the problem is, and add a note. Then have the application ship it directly in your issue tracker. –  May 04 '11 at 20:03
  • 1
    You can't control the application, but you think you can control the users? You're in the wrong field. – JeffO May 04 '11 at 21:06
  • 1
    At least they're not sending in a photograph of a printout of the link address (placed on a wooden table, natch). – Donal Fellows May 05 '11 at 10:44
  • 1
    Forget it, YOU CAN'T. This is the essence of 30 years in support. The only thing that changed in this 30 years is that today you get a ticket in electronic form, that has been derived from a mail that was sent by some web-app. That's all. Even the basic notion that the system he is working on might not be the only one on the planet can only be grasped by very bright users. Therefore, it's always "It" or "the system" or "the software" or "the window" that "does not work." – Ingo Nov 23 '11 at 13:58
  • Once, working at a company that made its money selling and configuring software, I got a message from one of our customer engineers that the demo ran half an hour and stopped. Worst bug report I ever got, and I never got any more details. – David Thornley Nov 23 '11 at 18:24
  • possible duplicate of **[Getting users to write decent and useful bug reports](http://programmers.stackexchange.com/questions/132248/getting-users-to-write-decent-and-useful-bug-reports)** – gnat Jul 31 '12 at 16:53

11 Answers11

15

One thing that I've seen several open-source projects do is to write up a standard "form" for bug reports, with sections for commonly-needed information.

If you have a bug reporting site or application your customers have access to, see if you can make a blank version of it the default text of the bug description field. Otherwise, put it somewhere they can find it (or where you can point them at), e.g. on your site or in the install directory of your product.

For your case, this could be something like:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("You" here refers to the customers)

The idea is to encourage them to provide useful information by providing a list of the kind of information that is most often useful.

Frits
  • 769
  • 4
  • 11
  • 1
    +1: When faced with a template, people generally try to fill it in. And if they don't, it does not take much of your time to simply ask them to fill the report. Also, by guiding them carefully, you may avoid the typical "It doesn't work!" – Matthieu M. May 04 '11 at 17:14
  • 5
    We implemented this pattern at work. 75% of all bug reports have a variation of "I expected it to work" in the "expected" field and "It didn't work" in the "actual" field. Sigh. – Charles May 04 '11 at 23:33
  • 1
    @Charles: Then close the report with a comment of “Resolved: no action”. – Donal Fellows May 05 '11 at 10:46
  • @Donal Fellows - I would reject it as "Duplicate" instead. – mouviciel Nov 23 '11 at 08:48
7

Usually I ask them for a screenshot of the error every single time, and eventually they start sending me the screenshot with their error request because they know I'll ask for it.

I still have to call them up for more info on occasion, but quite often I can see the problem just by looking at the screenshot

But I agree with @Mahmoud's comment that the best way is to get the application to send you errors instead of relying on the users.

Rachel
  • 23,979
  • 16
  • 91
  • 159
  • 1
    You've never had the case where you get a screenshot of a dialog box or something small that the user thinks is relevant but actually isn't? I get this all the time... – sevenseacat May 04 '11 at 23:15
  • Actually I do get that on occasion, but when I do I'll usually ask them for a screenshot of the actual error. After a while they get used to sending me the actual error – Rachel May 05 '11 at 12:14
5

The pessimistic take: You can't. It's the same situation like 40 years before, except there are more users, more systems, more applications.

(Note that a pessimist is just an optimist with experience.)

Ingo
  • 3,903
  • 18
  • 23
5

Make it easy for them to do or they won't.

Preferably make the easiest way that they can report an error the way that provides you the information you need. This almost certainly means automating the error reporting process in the software.

Keeping a detailed log file, and having it attached the error report is a start.

Alb
  • 3,359
  • 2
  • 20
  • 24
5

Reward your users for good bug reports, punish them for bad ones (well at least a little).

The user needs to understand that a good bug report is essential for you to fix the problem quickly and therefore is good for him as well, because he'll get the solution a lot faster.

So the first response could be something like "Okay, I have read your report but I don't know where to start. Can you tell me: Has this happened once? Is it a recurring phaenomenen? Could you try X and tell me what Y looks like after that?" and so on.

Quite often when people get this kind of feedback telling them what to do and telling them (directly or indirectly) what they didn't do in the first place they will learn. Maybe not immediately but the more reports they're filing the more they will (often unconciously) anticipate what you're going to ask them and provide the answer directly.

Yes, this is a step-by-step process and will not fix all the communication problems until tomorrow morning, but it's a start nevertheless.

Christian Seifert
  • 2,096
  • 12
  • 19
  • 2
    Punish them for bad reports: respond with a list of questions that they need to answer, and tell them to resubmit their support request when they have the information. Back of the queue! – Kirk Broadhurst Nov 23 '11 at 05:23
  • Sometimes it's sufficient to have a proper annotated screenshot of the bug/error together with meta information. [Usersnap](http://usersnap.com) is a small button which you can add to your web project to enable easy bug reporting. – Gregor Aug 21 '13 at 13:02
3

When you finish the conversation with the customer, say to them "The next time this happens, please have data item A, B, C, etc.. ready for me". Of course, this only works if these are the same customers repeatedly calling back. I have had success with this approach, where the users learnt certain key things that would a) speed up the call, b) make overall resolution much quicker.

If most of them are one-time callers, it might be best to update the "ERROR!" screen with text that says "You must gather data items A, B, C, ... before you speak to our representatives". This will really depend on how much control you have over the app, so it may not be do-able at all. This is not a sure-fire way either, but hopefully it will get the idea into the customer's head that screaming "ERRORZ PLZ HLP!!!" is not enough.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
2

Log everything you need. We have a rolling log file of x mb. If something bad happens, the user sends the logfile and often that's enough to fix a problem.

Another option is to use a remote desktop client to see for yourself what's wrong. These days that's as easy as letting the client download an exe.

Carra
  • 4,261
  • 24
  • 28
2

The problem with error messages in modern applications is that it is virtually impossible to include all the context which might be relevant. Anything from the processor architecture to the time of day can be relevant, which is why both error reporting and error handling are more art than science. Systems like apport-bug are useful in that they collect relevant information and submit it to you. Unfortunately, until the days of matter replicators, time travel and Heisenberg compensators, there's no way to be sure that the information you get from users will be enough to debug or even reproduce the problem.

l0b0
  • 11,014
  • 2
  • 43
  • 47
1

You can invest some time and add a 'Report a bug' red button in the top right corner of your app. When a user presses the button try to take screen shot, collect all available logs for the session, (may be its worth to) open the direct screen sharing to the user screen , show him the simple form and automatically send data to your server.

-Try to ask a user as little as possible if your app can get data itself. Screen resolution, OS version, user name, login, last actions and logs

-Assign a ticket to a user and provide him a link, so he know that he has bug number 1234 on www.yoursite.issues/1234

-Ask a user what he tried to achieve.

I think this all together, or even partially, can help you to receive enough data and show the user that he can help you to make your software even better.

ZeusTheTrueGod
  • 31
  • 3
1

You are going to have to ask pointed questions and be very demanding of them to give you all the answers. Sometimes their complaint of the problem will be interspersed with their plans for the weekend, complaints about their significant other, or the weather. Try to keep them on task and ask them, "Ok, when you do X but don't do Y, what happens?" Annotate their responses so you start to build a sequence diagram of events that you can later go back and debug.

Engineer2021
  • 3,238
  • 5
  • 28
  • 32
-2

The easiest way is to use a tool that can "understand" what actually the client wants. There are many tools, but maybe the best is Usersnap. See this story here.

Bogo
  • 101
  • 1
    This is little more than a link-only answer. Your answer would be stronger and more valuable if you explained why the tool answers the OP's question. –  Feb 12 '14 at 16:50