Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Do You Get Better Bug Reports From Users?

samzenpus posted about a year ago | from the that's-a-feature dept.

Bug 205

itwbennett writes "You can try to train them, you can try to streamline or automate the process, you can demand that all bug reports go through a middleman (i.e., a QA tester) or you can throw up your hands and accept that users will forever submit bug reports that in no way help you solve the problem. Like the stages of grief, you've probably tried or experienced all of these at some point. But have you found any approach that really works for getting useful bug reports from your users?"

cancel ×

205 comments

Sorry! There are no comments related to the filter you selected.

Follow up (1)

Anonymous Coward | about a year ago | (#44248943)

Your users aren't code masters and never will be.

Re:Follow up (4, Funny)

telchine (719345) | about a year ago | (#44248979)

It's not working can you fix it. kthxby

Re:Follow up (4, Funny)

FireFury03 (653718) | about a year ago | (#44249091)

Your users aren't code masters and never will be.

It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.

And this stuff happens again and again with the same customers... "one of our users is having a problem accessing some websites, please can you fix it?" - ok, so I have to go back and ask "which user" and "which websites", if I'm lucky the customer will give me this information, if I'm unlucky I get "I didn't ask". A week later I'll get an almost identical problem report from the same person about a different (but extremely similar) problem, and again none of the information I ask for _every_ time is included.

Also the great one that comes up occasionally is "this has been broken for a month and you haven't fixed it yet!".. well, if you'd actually told me that there was a problem I might've known to look into it, but since this is the first I've heard of it...

Re:Follow up (4, Insightful)

Anonymous Coward | about a year ago | (#44249487)

Your users aren't code masters and never will be.

It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.

And this stuff happens again and again with the same customers... "one of our users is having a problem accessing some websites, please can you fix it?" - ok, so I have to go back and ask "which user" and "which websites", if I'm lucky the customer will give me this information, if I'm unlucky I get "I didn't ask". A week later I'll get an almost identical problem report from the same person about a different (but extremely similar) problem, and again none of the information I ask for _every_ time is included.

Also the great one that comes up occasionally is "this has been broken for a month and you haven't fixed it yet!".. well, if you'd actually told me that there was a problem I might've known to look into it, but since this is the first I've heard of it...

Right. Because users are filing bug reports. They're calling for customer service/support. You get good bug reports by having good people answer the phone. I'll accept, "something broke," from a user. However, I find it inexcusable that a Helpdesk rep sends me a bug report that says the same thing or, worse, asks me to call the user for details. That being said, if you can't rely on Helpdesk or the user, then your software should be able to rollup everything you need to resolve the issue.

Re:Follow up (3, Interesting)

SQLGuru (980662) | about a year ago | (#44250205)

I had just sent the below list of things required in a bug report to a group of users/testers this morning......

In general, the following items should be included when possible:
â Reproduction steps
â Expected behavior
â Observed behavior
â If available, any related steps or values that worked (for example when a bug âoesometimesâ happens, itâ(TM)s useful to know when it works and when it doesnâ(TM)t)

Then, the trick is to reject or de-prioritize any bug that doesn't conform to the above. Train the users that if they provide accurate information, they get quicker response. It works for Pavlov.

Re:Follow up (1)

Shadow99_1 (86250) | about a year ago | (#44249709)

Requiring a user, after the fact, to recall an error message is futile. They simple have seen to many varied ones and their brain goes 'oh an error message' not 'oh a 504 error' or 'oh a invalid data type error'. This is when we have to write error handling code to be able to provide a text message, email, or simply a text file that records the details around a crash so you get the robustness you need to fix these types of errors without relying on iffy recall of users.

As an network admin, and closer to your 2nd paragraph, I would spend considerable time filtering fire wall logs for different criteria trying to see things like what sites are most blocked over a week to try to catch these sorts of things without having to have details from users. As strange as it sounds I would hear about connectivity issues often third hand (when they are all in the same building and I had an open door policy). So if I was not actively hunting for these things I knew I'd be having the CEO call me into his office (he never just dropped in to mine) and explain why he keeps hearing people are having issues with 'x' and if I didn't have an answer I'd have to hear him yell at me 'until I did'. I simply could not rely on users to tell me when they had issues or even correctly explain what those issues were.

Re:Follow up (5, Insightful)

ccguy (1116865) | about a year ago | (#44249893)

Requiring a user, after the fact, to recall an error message is futile. They simple have seen to many varied ones and their brain goes 'oh an error message' not 'oh a 504 error' or 'oh a invalid data type error'.

Believe it or not a user that doesn't remember the error message is not the worst kind of user.

I have some users that love translating text errors into numeric error themselves. Any time a page doesn't load, it's a 404. So that's what they report. "I'm trying to connect to thisdomaindoesntexist.com and I'm getting a 404."

Re:Follow up (3, Informative)

wisnoskij (1206448) | about a year ago | (#44249987)

That is nothing. I love it when users are overly specific, because they are always specifically wrong.

In user speak "My Password won't work." is code for everything, including an unplugged computer.

Re:Follow up (5, Funny)

Motard (1553251) | about a year ago | (#44249173)

You can reproduce the issue by getting their keystroke history. File an FOIA request with the NSA.

The NSA method works. (5, Informative)

Thanshin (1188877) | about a year ago | (#44249201)

- Record all their actions on a self overwriting one hour long file.
- Give them a "one button" way of reporting a bug. The button saves the user and the time, then waits for five minutes and then sends you the recorded actions file.

It's simple to develop and gives you a lot of information. It might be illegal in some countries.

Simpsons Approach (0)

Anonymous Coward | about a year ago | (#44248945)

Can't somebody else do that?

Re:Simpsons Approach (1)

wonkey_monkey (2592601) | about a year ago | (#44249323)

Tibor will know what to do.

Make them feel connected. (3, Insightful)

MindStalker (22827) | about a year ago | (#44248947)

I think bug reporting was one of the things that the early Mozilla project did right. If anything give your users tools to track down the source of the bugs themselves. Your few power users who are developers, if you give them tools to view the stack trace or other such things often will, and they might be able to do much of the work for you.

Re:Make them feel connected. (2)

miketheanimal (914328) | about a year ago | (#44248965)

Our power users are people who are good at selling you stuff you don't actually want. None of them are developers.

Re:Make them feel connected. (1)

Anonymous Coward | about a year ago | (#44249681)

So teach them that they have to sell the bug to get it fixed.

Re:Make them feel connected. (3, Insightful)

DNS-and-BIND (461968) | about a year ago | (#44248977)

How is a USER supposed to track down a bug? They're users.

Sounds to me like the developers just didn't like dealing with bugs and wanted the users to do it all and present them with a gift-wrapped solution.

Re:Make them feel connected. (4, Informative)

Dupple (1016592) | about a year ago | (#44249051)

How is a USER supposed to track down a bug?

In the same way a beta tester does (among other things). Every time I do 'X' then 'Z' will happen instead of 'Y'. Please fix.

Recreating a repeatable problem is a pretty good start. In my experience the hardest part seems to be getting the average user to explain what the problem in a way that can be understood that is beyond 'it just doesn't work'

Re:Make them feel connected. (2)

Shavano (2541114) | about a year ago | (#44249903)

One of the commonest problems is that the error occurs in a way that's not repeatable from the user's point of view. For example, he's editing a file and the software does something weird. Was it that I pressed the A key after I pressed the ESC key? Was it because I pressed the space bar while moving the mouse? Was it because the program's window was maximized in the right display instead of the left display? Was it because the program auto-saved while I was editing and part of my file had swapped out? Was it because there was a glitch in the interaction between the program I'm running and a license key verification subsystem? Or was it something so completely below what I as a user can see that I have no hope of giving you useful information?

The best you can do to find out what the user was doing is write a log file and have an error reporting function that automatically sends the log file. Also, you can include every system request and every subroutine call. It might also be helpful to have the program take a screen shot and include that in the error report. Might be illegal though without the user's permission, and some failure are too hard to have the program do any of that stuff automatically. But then you can have another process monitor the main application and do the automatic reporting actions. If the main program terminates abnormally, you get an automagic bug report.

Re:Make them feel connected. (1)

Kjella (173770) | about a year ago | (#44250031)

There's an 80/20 ratio here, if you fix the 80% that fail the same every time then you wouldn't solve everything but you'd solve a lot. And sometimes the exact set of conditions is obvious after a few tries (Example: A chess program I use, if you have hit "analyze" but is still reviewing the options and haven't started it, get challenged to a match (usually a rematch) and hit cancel in the analysis dialog, the client crashes. First time I thought random crash, second time waaaait didn't it crash before on something just like this, third time it was "I think it'll crash if I hit Cancel now" and I was right). Other things are just random like "the game crashes at random intervals", you can't catch them all that way but some or most is better than none.

Re:Make them feel connected. (1)

Impy the Impiuos Imp (442658) | about a year ago | (#44250149)

You've already left 90% of humanity in the dust.

Better to teach programmers to make the effort to write test fixtures to exercise the hell out of things.

Why, for the past six months, does YouTube and everything else using that video player system (flash?) crash when doing a jump, about 1 out of 10 times? A simple fixture clicking different spots randomly every 5 to 1/10th second should make finding problems easy. When it can survive overnight, then you can relax a little.

Re:Make them feel connected. (0)

Anonymous Coward | about a year ago | (#44249055)

Yes please :)

Re:Make them feel connected. (1)

khallow (566160) | about a year ago | (#44249461)

How is a USER supposed to track down a bug? They're users.

They're users because they're using the program in question. They run into the use cases that trigger the bug.

And an open bug reporting system means that users can get educated on what sort of bug reporting actually helps developers.

Re:Make them feel connected. (1)

Anonymous Coward | about a year ago | (#44249617)

The user may be more of an expert with the system than you, the designer, are. They may also be more motivated to fix the error. They are also not necessarily any less intelligent because they reside in a different department or have a different career (a common assumption).

True, they may not be programmers. But they just might be; or they might be enough of a power user they can do all the work for you.

No (1)

miketheanimal (914328) | about a year ago | (#44248953)

No. Well, not yet, but I don't expect that to change anytime soon.

Force them to be better (2, Insightful)

Anonymous Coward | about a year ago | (#44248963)

We have a big internal web app, when it throws an error it will log that error as part of a graceful error handling process. (Page, scope vars, user info, time, etc) From there, the reporting system requires a unique bug tracking number (the error number logged above) and it checks for uniqueness and to see if it exists before it lets you open it. The only edge case it doesn't catch is when our tracking mechanism is also broken and these tend to be severe outages that are pretty easy to diagnose and reproduce. That is the only bug that can be reported with an email, all others are responded to with a "Please log in the application and we will route it appropriately"

Re:Force them to be better (1)

magic maverick (2615475) | about a year ago | (#44249303)

Force them to be better. By beating the required information out of them. They'll soon learn to pay attention to what they did wrong, and to any error messages, if they consequences of not doing so are a thorough thrashing.

Of course, in some nancy pancy places they frown on beating the users. In those cases, I guess you could try the carrot approach. Give them a chocolate coin for every useful detail in the error report.

Have a clear list of what is required and what is helpful for any error report. Then, make it clearly visible and accessible (in the help of the application, in other documentation, etc.). Require users to complete a checklist before they can even submit a report via the bug report system. Refuse (or 'forget') all reports submitted via email, phone, or any other method that is not the bug reporting system.

No (1)

vikingpower (768921) | about a year ago | (#44248971)

Period ( . )

Send a Screenshot (1)

Saethan (2725367) | about a year ago | (#44248985)

Generally if we can ingrain that a screenshot and a username will be much more useful than any first-submission of a bug, we get things done faster. Most of the time we get the screenshot and find out PEBCAK...

Re:Send a Screenshot (1)

Cwix (1671282) | about a year ago | (#44249039)

That would be PEBKAC. Although I prefer PICNIC. Problem in chair, not in computer.

Re:Send a Screenshot (2)

bickerdyke (670000) | about a year ago | (#44249161)

Layer8-error

ID-Ten-T error (ID10T) ...

Re:Send a Screenshot (0)

Anonymous Coward | about a year ago | (#44250179)

Generally if we can ingrain that a screenshot and a username will be much more useful than any first-submission of a bug, we get things done faster.

You'd be amazed at how badly some people can screw up a screenshot, mainly by (A) cropping out the important parts or (B) scaling it down so that it's illegible.

Yes, i believe (0)

Anonymous Coward | about a year ago | (#44248997)

Developer and user relationship is one based on love, forget about streamlines and tickets open regarding the ticket tool itself, love is all a user needs.

Depends on the user base (3, Informative)

Enry (630) | about a year ago | (#44249009)

I've worked in support organizations for 15 years. In a commercial environment where you can afford the staff, having a tiered approach works best - you have a help desk to gather and refine the questions and answer the small stuff, then work your way up to the engineers that wrote the code. The tough part of that is having a skilled enough help desk to know when to skip the canned questions and just forward a request on once you have the right information.

For organizations without those resources, you need to rely on the user base to be the help desk. Give them as much concise information as possible and frame the bug submission so that any and all needed data is in the report. Then it's up to the developer to give good information back to the user.

As an example, I had a problem with my laptop's trackpad going wonky. Ubuntu made it really easy to compile information about my system and submit it as a bug report, then open it for me so I can add any additional text I wanted. The answer I got back asked me to try a different kernel, and included well-documented links and information on how to get and install it. Just saying something like "yeah, go grab something out of backports" doesn't help the user if they have no idea what you're talking about.

Depends on your users (4, Insightful)

dkleinsc (563838) | about a year ago | (#44249023)

If your users are, say, someone who works in a different department of the same company as you do, then I've found that the best approach is to positively encourage them to send me reports. If I can't figure it out from the report, I'll even walk over and ask them to show me exactly what they did to cause the bug. When I do that, I give them some tips on how to write a report that explains that more clearly: "I logged into the website, clicked 'Foo', entered 'baz' into this box, then clicked 'Submit'. I got an error page instead of this other page I was expecting."

If your users are mostly developers, then by all means give them easy access to stack traces, memory dumps, etc.

If your users are mass-market end users, then include with your application a system that tracks user actions and sends it (along with a crash dump) to you at the user's request if there's a problem.

If your users are calling in to your company to complain, plan on using some kind of desktop sharing software so that the user and you can see exactly what happened.

If your users are dumber than a pack of hammers, then I have no answers for you.

Huh? (0)

Anonymous Coward | about a year ago | (#44249031)

You hire someone for fucking quality control you cheap bastard. USERS ARE NOT THE ONES WHO SHOULD BE MAKING BUG REPORTS. The software industry has been lazy for the past 25 years. Fix your fucking code before you release it, not after.

Re:Huh? (0)

BreakBad (2955249) | about a year ago | (#44249321)

QC tells developers that their product sucks and then tells the boss their product sucks and why. Then the developer has to fix things in a timely manner like their getting paid or something....its horrifying. OTOH, user's just give vague feedback and allow the developer more opportunities to be condescending...much like it when IT snickers at you when you can't do something because you don't have the correct permissions/roles. This process also allows the developer opportunities to manufacture job security through poor design and/or setting self serving goals.

Re:Huh? (1)

RaceProUK (1137575) | about a year ago | (#44249883)

You must be incredibly lucky to have a test department with millions of machines with every conceivable variation in environment possible.

Users don't *owe* you a good bug report (-1, Flamebait)

Anonymous Coward | about a year ago | (#44249047)

You *owe* them a bug free product. If you did your job properly, this complaint would be moot.

Re:Users don't *owe* you a good bug report (2)

Rob the Bold (788862) | about a year ago | (#44249231)

You *owe* them a bug free product. If you did your job properly, this complaint would be moot.

OK. How you gonna get there, Chief? Certainly not by testing, since that would involve testing which means "using". Maybe not by end users but by someone "using" the software, whether you call them QA or whatever. So, what, you just write it bug-free in the first place? I don't know what you make, but I think it's safe to say that you should be paid more.

Re:Users don't *owe* you a good bug report (1)

Anonymous Coward | about a year ago | (#44250173)

Just because you can't reasonably deliver doesn't mean that you don't owe your customers a bug free product. They didn't pay for a buggy product.
What you have to do is to start thinking of your customers like the one who pays your bills, not the one who causes you all of your problems.

Re:Users don't *owe* you a good bug report (1)

Enry (630) | about a year ago | (#44249833)

For small stuff, yes. But we're now in a world where software and hardware is complex. Even in an environment like Apple where they have tight control over the hardware, there's variations between operating systems and their hardware offering that make it difficult for a company to write a single app that does it all. Then look at the PC world where it's pretty much a free for all.

Worse error messages (5, Interesting)

sheetzam (454981) | about a year ago | (#44249059)

When writing error messages, don't have it spit out something sensible. Have it spit out something completely crazy but memorable, which you can then grep the code for. Something along the lines of "The Cake has hit the Fan" or "The Chickens are eating Pie". This improves the odds the user will remember it and report it correctly, giving you some hope of finding where the bug is in the code.

Re:Worse error messages (3, Insightful)

Rob the Bold (788862) | about a year ago | (#44249191)

When writing error messages, don't have it spit out something sensible. Have it spit out something completely crazy but memorable, which you can then grep the code for. Something along the lines of "The Cake has hit the Fan" or "The Chickens are eating Pie". This improves the odds the user will remember it and report it correctly, giving you some hope of finding where the bug is in the code.

Or make it copy-and-pastable so no human memory is required. Or log it and make sending the log easy enough for your users. A nice user message followed by a more detailed procedure unwind or whatever applies in your application can be mighty useful.

Re:Worse error messages (0)

Anonymous Coward | about a year ago | (#44249517)

Or make it copy-and-pastable so no human memory is required.

That won't make users copy and paste it. They'll still swat it away and then call or email with a vague complaint.

Re:Worse error messages (0)

Anonymous Coward | about a year ago | (#44249349)

"The Cake has hit the Fan"

I think I remember that episode... Moe, Larry, and Curly delivered the wedding cake but couldn't figure out where to put it. Ah! Right here.

Fortunately, there were tables full of pies that weren't affected. But some of the well-dressed guests, having been creamed by the cake, weren't happy...

Re:Worse error messages (1)

RaceProUK (1137575) | about a year ago | (#44249901)

Purple Monkey Dishwasher

Re:Worse error messages (0)

Anonymous Coward | about a year ago | (#44250249)

No, if you're application is ever in that error state you should know about it, and know why it happened immediately - not when the user decides to report it.

Speak to the Submitter (3, Interesting)

Capt.Albatross (1301561) | about a year ago | (#44249067)

The sooner, the better. You need an agile bug response process.

Forms (1)

Anonymous Coward | about a year ago | (#44249081)

The easiest way to get goo bug reports is to have a good way to submit them. Have a form, have the form fields clearly labeled. Include documentation indicating what sort of information you need. Make it clear, short and simple. Have one person on the team whose job it is to follow up on bug reports, get more information and update the users on the progress of the bug. If users think a bug report is a black hole and nothing gets done they won't send good ones.

Re:Forms (1)

Somebody Is Using My (985418) | about a year ago | (#44249831)

Even with forms, don't bet on getting clear bug reports.

Aside from all the other issues mentioned earlier, there is another reason users do not provide good bug reports: time. It takes time to write up a proper report, explaining all the details (what they were doing, what they expected the program to do, what it actually did), provide .LOG files, screenshots, annotations, etc.

A form can remind them of what information they need to provide, but it won't make the actual data-collection any simpler. And users frequently already have enough on their plates without requiring them to take the time to write up all the necessary information. Add in to this their frustration that the program "doesn't work" and they have little incentive to put the effort into writing up a detailed synopsis of the problem. They just want to do their job, not have to deal with (what they consider) YOUR job.

In short, don't expect the users to provide good reports for you. Better to build the necessary tools into your software so that it can collect most of the data you need automatically.

Re:Forms (2)

BVis (267028) | about a year ago | (#44250141)

Not to mention the 'horse-to-water' problem with a formal ticketing system. If you have a phone, and they know your extension, they'll just call you directly instead of, you know, actually doing anything. And unless you've got C-level buy-in on the ticketing system, telling the user to go open a ticket is usually a Career Limiting Event.

No, the way to enforce usage of a ticketing system is to not tell the users about any other way to contact you.

Bug template (4, Insightful)

Anonymous Coward | about a year ago | (#44249083)

In your bug tracking system, provide a bug template they need to fill in.

Encountered situation:
Expected situation:
Error messages, if any:
Steps to reproduce (please provide screenshots if appropriate):

If the template is not fully filled out, simply throw it out with "insufficient information/cannot reproduce". Eventually your users will grow up.
Also, there's nothing wrong with walking up to a user's desk (if physically possible!) and ask them to show you what they did.

Use Forms (0)

Anonymous Coward | about a year ago | (#44249087)

This kind of idea of dedicated forms works fine and reduces the clutter:
http://www.linksceem.eu/ls2/user-resources/user-support/access-issues-login.html

(in fact, if you force users to pass through the process first time before entering the system,
magically things work smooth)

Re:Use Forms (1)

v1 (525388) | about a year ago | (#44250091)

agree with the forms. You can't expect good answers if they're not replying to good questions.

the BARE minimum:

1. what were you trying to do?
2. what happened?
3. what were you actually expecting?

That's not necessarily a good list to give to a user, but this is what we tell our front line people to keep in mind when taking a call. There will be two basic limiting factors with online ticket forms. (1) people may not understand the questions and be intimidated enough to not be willing to use the system and (2) duplicate tickets. Make sure whatever you use can handle both issues.

If people aren't using your forms and you've done due diligence with making them aware of them and the need, and they're not getting used, don't blame the users because it's probably something you're doing wrong.

Probably the most frustrating experience for a user is to enter a ticket, and have it "closed" without their having believed it is fixed. Maybe it's fixed and they just didn't even look. Maybe it was changed to work properly and they don't know the new way to use it. Maybe they fixed the problem the customer described, but not what they MEANT. Maybe the fix didn't actually fix the problem at all, or didn't completely fix it and the customer's symptom remains. Maybe they've just been avoiding where the problem is for the last two weeks because they didn't realize it had been fixed on day 2.

Feedback and communication make tickets work.

- make sure you understand the problem. users often try to diagnose the problem and tell you what's wrong, instead of WHY they think it's wrong. here we say "don't check in diagnosis, check in SYMPTOMS." Users frequently mis-diagnose problems. "I can't send email" could stem from "I don't have internet". "My hard drive is dying" could stem from "my computer keeps suddenly shutting down". The entire process is completely dysfunctional if you don't understand their problem. Make sure your form gets symptoms, they're more important than problem descriptions.

- followup is costly, but you NEED to do it. So many ticket systems skip this it's sad. NOTHING frustrates a user more than to have their ticket closed without their believing their problem is fixed. "xxx is fixed. if we don't hear back from you in 24 hrs we will close the ticket" isn't the best solution, but should be considered a bare minimum. If the customer replies back that they don't feel it's fixed, don't just dump it back into the tier 1 queue. Escalate it, increase user interaction, get more information, get feedback. DO NOT rely exclusively on the information in their "it's still broken" reply message. It's time to make a phonecall for more effective live two-way communication.

- prioritize tickets. not just in order of submittal but in order of urgency. tickets that have been back-burnered for awhile should get a bump to their priority. More than one level's worth if needed. The person doing the bump should probably NOT be the one processing the tickets. It's been my experience that an objective fresh viewpoint is needed to make sure that unpleasant tickets don't languish on hold.

One place I worked at recently, the users had almost totally lost confidence in the ticket system. It required me to have comprehensive personal followup on tickets for a solid year before people started trusting the system again. Techs in charge of the queue were summarily deleting vague or "cannot reproduce" tickets with not so much as a response. Tickets were also silently closed whenever a tech though they had fixed the issue. (several tickets had been freshly ressubmitted over a dozen times because the tech didn't understand the user's problem and thought he had fixed it and the user was just too dumb to realize it) Tickets that had several dups in the system from the same user or few users were deleted en mass just to clear the clutter. ("if it's still a problem I'm sure they'll submit another ticket shortly") It was terrible. They had conditioned users to submit duplicates almost daily until they thought their problem had been fixed.

You really need three ticket queues. One for immediate action "break/fix", one for process improvement and special requests that can be handled quickly "requests", and one for major changes and large requests "projects". Keeping all three classes of tickets mixed into one list clutters and lowers focus. Have users submit only to the break/fix, and move tickets as necessary.

When a user is entering a ticket, the system MUST automatically try to find an existing ticket for the same problem. Use very loosely matching rules that can provide a small number of most likely duplicate tickets. Allow users to say "yeah, that. that's happening to me too". Don't just dump them out, add the user to the list of submitters for that ticket, so they can be kept in the loop, notified when it's fixed, etc. This is SO much better than getting 15 tickets in 10 minutes because the scheduling database crashed. Without this combining, you either have 15 tickets for 1 problem, or 1 ticket with only one name on it and one followup when it's fixed, and neither is a good solution. Of course also allow the techs to merge tickets in the same way, combining information AND users.

Along that line, techs need to be able to EASILY break up tickets into separate tickets when a user submits several issues at once (it happens frequently) or when a fix is going to require a multi-pronged approach. (possibly from several techs with different expertise) If you make combination or breakup of tickets difficult, they won't get used as much as they need to. The user isn't the only one that needs to find the ticket system easy to use to encourage proper use. Listen to your techs when they raise concerns about ticket system usability.

We had a game called "ticket-tag". Sometimes I thought a ticket was Jason's area of expertise, and he thought it was mine. And we would switch owner of the ticket back and forth several times before I would call ticket-tag and get the service manager to make a call. More often than not Jason got it, but sometimes I did. You need to have a service manager that can help keep the wheels greased and resolve deadlocks.

I suppose I could go on for awhile but this is enough for today.

Just ignore them.... (0)

Anonymous Coward | about a year ago | (#44249099)

Direct all bug reports to /dev/null

Not Up to Users (0)

Anonymous Coward | about a year ago | (#44249105)

It's the responsibility of the programers and developers to test their software, not pawn this responsibility off on the users. It's all about $.

Re:Not Up to Users (1)

Dunbal (464142) | about a year ago | (#44249233)

Yup, maybe we should start paying for software with a small percentage of counterfeit money. You know. And ask them to file a report when that money doesn't "work". And maybe get around to fixing the problem. Eventually.

The BUG! Button (5, Interesting)

AndyCanfield (700565) | about a year ago | (#44249109)

On every page of the site that I did for this company, in the upper right corner, there is a button labelled "BUG!". Click on it and a dialog box comes up that says simply "What's wrong with this page?" and has a big blank area to fill in. The dialog box has a "Submit" button.

What is not visible is that the JavaScript code for the BUG! button is grabbing all the information it can from the browser itself - what the current URL is, all the global JavaScript variables, name of the current logged-in user, time and date, browser type, web page contents, etc. All grabbed automatically.

And all stored in a special file on the server. The only thing the user has to tell me is what she doesn't like about that page.

The BUG! button was invented - by me - as a reaction to Bugzilla, which seems to be designed to keep users from reporting problems. I can ignore pointless bug reports, but I want to hear everything.

Re:The BUG! Button (1)

Qzukk (229616) | about a year ago | (#44249359)

Click on it and a dialog box comes up that says simply "What's wrong with this page?" and has a big blank area to fill in.

"It's not working."

Re:The BUG! Button (2)

StormReaver (59959) | about a year ago | (#44249561)

Bug reporting has to be extremely easy for users, or they just won't do it. Bugzilla is an absolutely excellent, unsurpassed example of how to prevent users from reporting bugs in software. It is absolutely wretched and damn near unusable.

Your idea is excellent: let users complain in their own words, but have the software transparently gather all the runtime information needed to reproduce and identify the problem. That should also work for desktop apps written in Java or C#, which is something I think I'll create for my own apps.

Thanks for the suggestion.

Re:The BUG! Button (1)

eulernet (1132389) | about a year ago | (#44249717)

Nice idea !

In my case, when the program catches an error, it displays a text input and a Send button.

I expressedly ask the users to explain how they reached this message, and I encourage them to report bugs in order to improve the quality of the program.

When they click Send, it sends a mail containing their message along with the (hidden) callstack and the error message.

Most of the time, people are unable to explain how they encountered this error, but at least they always press Send !

Re:The BUG! Button (1)

Chris Mattern (191822) | about a year ago | (#44249861)

The only thing the user has to tell me is what she doesn't like about that page.

And odds are that'll be, "It doesn't work."

Re:The BUG! Button (0)

Anonymous Coward | about a year ago | (#44249881)

And as a small followup to this: once you're automatically sending up things like global JS variables, consider adding extra "logging" variables. Is it useful to have a little bit of "what has the user done in the past" sort of information? Then store that somewhere, and when a bug report happens, you're getting the information with the bug report too.

That way, in addition to seeing "Oh, globalInformationThingie is zero, that's the problem", you might also have "lastGoodValueOfGlobalInformationThingie=99999999" and you can immediately say "hey.... looks like some kind of overflow it's an invalid zero now, but in the past it was a stupidly large value! Maybe I should check if there is some field where we're checking for a max length or size on that...".

Similarly, you can store some log of what menus people have clicked on, so instead of just the current value of menu options, you have some "history" of how they got there.

This may or may not be useful for your program/site, depending on what you are doing, but I've often found that once I see the current values, I know what _is_ wrong, and then my next question is "ok, what the heck did they do to make it get to that state, there isn't supposed to be a way to get that value into that variable...". So preemptively building in extra logging and tracking information can make it easy to answer these questions if the user just types in "I clicked some buttons and it broke!".

Re:The BUG! Button (0)

Anonymous Coward | about a year ago | (#44250267)

I'm also an advocate for this approach (that is, providing as much context info behind the scenes as possible).

So much so that I've been writing a service to allow anyone to do this with a few lines of code: http://bugreportjs.com

James

You could try asking them (0)

Anonymous Coward | about a year ago | (#44249115)

I've filed many bugs against certain open source projects only for the developers to respond with "How am I supposed to fix this? Why aren't you telling me anything?". I'm not sure why they think the first submission will contain everything they need to replicate the bug, but that seems to be the expectation.

Re:You could try asking them (1)

Rob the Bold (788862) | about a year ago | (#44249311)

I've filed many bugs against certain open source projects only for the developers to respond with "How am I supposed to fix this? Why aren't you telling me anything?". I'm not sure why they think the first submission will contain everything they need to replicate the bug, but that seems to be the expectation.

That's a fair request. When the developer is secretly thinking of a bug report format and required additional information and users are required to guess what that is, they'll probably give up after one guess. After all, they didn't develop the product, so without telling them what's required to debug and how to report it, they'll probably never guess the secret. Refining the report with some back-and-forth would go a long way in cases where you're dealing with a user capable and willing to provide this extra info.

Of course, there will be users who just can't help that much due to their own limitations or the time they have available to debug your product, so their reports will probably never be all that helpful except in a statistical sense. That's OK. Not everyone is a programmer or QA specialist or whatever. You're probably not qualified to listen to a piano recital and give the performer constructive criticism either, even if you knew it didn't sound as pleasing as you would've liked.

Re:You could try asking them (1)

hendrikboom (1001110) | about a year ago | (#44250313)

It may or may not be a fair request, but it's only useful if the developer tells the user what information he needs and how to go about getting it.

-- hendrik

Re:You could try asking them (1)

hendrikboom (1001110) | about a year ago | (#44250005)

Which is why, whenever I file a bug report, I make a point of asking what information I should provide that might help diagnose a problem. In case the developer is as clueless about responding to users as the typical user is about responding to developers.

-- hendrik

Use the software yourself (1)

bAdministrator (815570) | about a year ago | (#44249123)

There are many bugs that would easily be detected by actually using the application on a daily basis.

Users do not work for you. When they do post bug reports, it is most likely in frustration.

Re:Use the software yourself (2)

Rob the Bold (788862) | about a year ago | (#44249409)

There are many bugs that would easily be detected by actually using the application on a daily basis.

Users do not work for you. When they do post bug reports, it is most likely in frustration.

Providing that the developers actually have the ability and resources to do that. Most (much?, some?) software isn't developed for use in the programmers' domain, and real-world deployments often have conditions that aren't fully replicated or anticipated even in even a good simulated environment. Your developers probably don't operate a retail POS or limestone quarry or credit card call center or whatever environment the product is used in.

Not that this is an excuse not to do your best to test it out before handing off to the end user, it's just that the conditions that make the bugs appear are sometimes the very conditions you don't anticipate and can't or don't know to test.

Re:Use the software yourself (1)

bAdministrator (815570) | about a year ago | (#44249537)

Programmers have to know the domain for which they are developing.
You have to make using the software part of your time, just as code review shuffles through roles.

For your example, if your software has so many unknown states when shipped, it's fair to say it's based on luck if it works right.

You would actually need an environment where you could map out states, and simulate input devices.
Software development is still young, and I don't think we know how to do it right yet.

Re:Use the software yourself (1)

RaceProUK (1137575) | about a year ago | (#44249955)

There are many bugs that would easily be detected by actually using the application on a daily basis.

I don't know about you, but I don't have a pressing need to know what some ice-cream trucks in Switzerland are doing at a particular moment in time (The system I work on is fleet vehicle tracking and management). I have more important things to do, like watch TV or play games.

Fields with fixed format + lots of logging. (1)

Anonymous Coward | about a year ago | (#44249127)

Over years I've devised a system that works very well. I've used it mainly for web apps, but I'm sure it can be adopted. The key is:

A) Limited number of predefined fields
B) Extensive logging on backend.

ad A) I like to use following fields information:
- User you're logged in as (login/email)
- Page that you've encountered error on (link).
- Screenshot (of whole screen! - add an flash app to take screenshots if possible).
- Operating system / Browser (sometimes needed, sometimes loggin on server is sufficient) best to have predefined list with radio buttons.
- Bug description in following format
    After I did ......
    happened .....
    Instead I'd like for ..... to happen.

ad B)
- Logging every visit, every page view with:
    - Operating system, browser, browser dimensions.
- New relic.
- Airbrake.io (or alternative / equivalent for your language).

With those two things you should be able to track most of feature requests (otherwise known as bugs).

Show the reporters of bugs you care and appreciate (3, Insightful)

Rooked_One (591287) | about a year ago | (#44249141)

... their efforts to reach out to. They are actively trying to help you make your program better. I am not a programmer, however growing up in the pre-nintendo tech days, I know what a bug looks like. I've reported many bugs, and the only response was from Charlie on the Natural Selection (Half-Life mod) team. As much help as he had been in the past when I lost my account info and helped me retrieve it when he was just a one man team, basically, the response back was lacking. I chalked it up to being busy.

If you're telling me you have time to program, but can't take the time to read an email that's bullet-pointed with very specific details and at least respond like a grateful human, then I am just going to say you have way to many e-mails to respond to or you're lying. In the prior, get more help. In the latter, please seek help.

follow-up (2)

Vasudev Sharma (2914083) | about a year ago | (#44249147)

No matter what process you employ it will fail, what you need is someone who is willing to follow-up with the users and step in their shoes, I have realize users are always willing to report a bug as long as it makes them feel important and FOLLOWUP.

Screen Capture (2)

radius1214 (1082581) | about a year ago | (#44249151)

I believe it was Google who at some point had an option to highlight the portion of the page that showed the problem, as well as submit a comment about it. Being able to see exactly what this user is talking about would help quite a bit when I go to fix a bug.

Multiple Methods (1)

Murdoch5 (1563847) | about a year ago | (#44249153)

First stage is a php form I wrote which asks them very directed questions. They have to answer questions like "What was running on the computer when the bug occurred. Were you running the software in VM, Did you follow the setup directions properly, Did you download the newest version from the test server etc....

Second stage is they let the form take logs from the computer, I automated the process so the form takes what it needs. They literally hit start and go have coffee or something well it works away. Once that is done I get an email with the form data and the logs.

Third step is reproduction, I give the data to another user and asked them to reproduce the issue, if they can't then I visit the submitter if possible or ask for them to take a video of it occurring. If they can then I also grab the data and at that point I have what I need to fix the bug.

Once bugs are fixed both testers have to try and reproduce the issue and so far it's been very very rare that they can. The user can only answer the questions you ask them and I hate when QA tester ask bad question and complain about useless answers. Ask the right questions and you'll get the right data. You also have make sure developers are building great logging systems. A logging system should be good enough that with out the tester inputting to the issue you can see all the data you need! If you can't then the logging system isn't designed well enough and needs to be redone.

Encourage, Listen and Reward (1)

Sla$hPot (1189603) | about a year ago | (#44249165)

Encourage and make it easy for users to send feedback.
Listen to complains, no matter how rude.
Reward the users by acknowledging their reports and by actually fixing the bugs or by adding requested features when it makes sense.

Re:Encourage, Listen and Reward (0)

Anonymous Coward | about a year ago | (#44249699)

As someone who has spent many an hour of frustration on bug trackers, this would be my list:
- Improve your own reading skills.
- Stop being in denial about every sodding bug filed.
- If a bug report reads ‘If you do X, Y happens’ don't close it with ‘no steps to reproduce’ without first trying to do X.
- Don't prohibit people from filing bugs ‘because there are so many open bugs already’.
- Actually try to use your own software to do serious work for once.
- Don't be an ass.
I've seen the problem from both sides of the fence (dev and user) and the problem almost never lies with the submitter of a bug.

Have tried everything (2)

Stormcrow309 (590240) | about a year ago | (#44249177)

Hello everyone,

I have tried a bunch of ways. Trained the 'expert' users in the area on how to put in a better ticket. Sent tickets back to them because of lack of information. Judicious of cattle prods and a tack hammer... However, users will use what method is easiest to them, which tends to be:

  1. Calling someone they know directly
  2. Emailing someone they know directly
  3. Emailing the ticket capture email address with 'Call me'
  4. Calling the service desk
  5. Screaming at someone from IS in the hallway
  6. Emailing the ticket capture email address with a long email chain which tangentally mentions the issue somewhere in the middle
  7. Complaining to coworkers
  8. not doing anything
  9. Log into the ticket system and put in 'call me'

Having worked in application support for 5 years (1)

Tomji (142759) | about a year ago | (#44249205)

I got one trick for users that just cannot explain properly what their issue is. Nowadays everyone got phones that can record a video, make them record their screen (this skips the step of having them install a screen capture tool).

Screen shots/sharing (1)

Mhrmnhrm (263196) | about a year ago | (#44249209)

If your organization is small enough, send screenshots together with the report, or if you have some kind of desktop sharing ability (remote assistance, Lync), take your dev through the process of how to trigger the bug. Just had an issue yesterday where they couldn't reproduce it, so we fired up a screen sharing process, they had me load up the Firefox debug console, and I went through the steps... turned out to be my mouse having a higher dpi than what they were using, so instead of getting floats, my system was handing them doubles.

oops (1)

mt1955 (698912) | about a year ago | (#44249213)

posting to revert mod mistake

By overriding the default err handler (0)

Anonymous Coward | about a year ago | (#44249223)

For compiler structured error handling & piping those to a log since they are "more scary"/"less intelligible" to non-coders! Then, also providing users a friendlier message to contact me via email, pushing the "E.Message" (from a variable E:Exception type), along with the notice to mail me that message OR the contents of %AppDir%/APKErrLog.txt which contains the actual structured err handler's data dump!

(Accessible since I override the "controlbox" in the upper left-hand side corner of EVERY Window/hWnd, & that simply spawns notepad.exe so they can copy/paste the errtrap log's data into said email to contact me with it).

It's worked out very well in this app so far the past year now (helped me take it from version 5.0++ to present 9.0++ in fact):

---

APK Hosts File Engine 9.0++ 32/64-bit:

http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 [start64.com]

---

* Recently, I tested that ware above with a neighbor's kids - and yes: They beat the heck out of it, operating it way, Way, WAY "out-of-order" (vs. the order I intended for it to operate in, and it's clearly shown how that's done, including "wizardy" 'do this next' type stuff), but they didn't "follow directions" anyhow, & busted it a couple times! Well, in the end after that - that made me realize I had to account for that, too! In the end? The app came out much better than it was before version 9.0++!

APK

P.S.=> It's a working system, & that I received much data + great feedback for improvements from many testers the past year++ with! Yes - you can *try* to find all of your "bugs" or "useability issues" yourself, but good luck to that, especially when YOU designed the app - you have "set ways"/"set patterns" that "get in your way" imo, believe-it-or-not, when users, don't.

... apk

Give the user an incentive... (1)

fatgraham (307614) | about a year ago | (#44249365)

Security bugs in chrome, firefox etc get actively hunted down because of the explicit cash rewards, it clearly works.

I recently "submitted a bug" in an IOS app for a restaurant (web contact form, no email, in-app submission etc), they said I'd get a "free stamp" (collect 5, get a free meal etc) if I sent them the crash logs. Not a big deal, (I'm a developer so not difficult for me to do) but even a small incentive encourages me to actually DO it.

If you/parent company can give away something like like loyalty-card points which relatively cost you nothing, give it away like it's halloween.

Re:Give the user an incentive... (1)

HxBro (98275) | about a year ago | (#44249413)

Like a cattleprod every time they don't submit a good bug report ?

bzzzt! (in true bofh style)

Users... (0)

Anonymous Coward | about a year ago | (#44249395)

That's your main issue... get rid of the users, but fix will be 100% easier!

Have you tried submitting a bug report lately? (0)

Anonymous Coward | about a year ago | (#44249417)

Writing good, useful bug reports is surprisingly hard. Even for people who consider themselves dyed-in-the-wool developers. They may have an idea of where the problem is and cut to the chase... only to find their assumptions and hunches were wrong. Users have a much more limited view and so often don't even stop and think what may be needed. Even as a seasoned troubleshooter it can be quite hard to drop the right information on a sysadmin's plate. And it can get immeasurably worse if the phone screen turns out to be too dense to penetrate. Or if the responsible fixer (dev, techie, admin, what have you) refuses to cooperate in some way. Sometimes that's justified, but not always, certainly not.

Plenty of automated solutionising solutions (you know the things, the "we haven't sent your request yet, please look at these umpteen useless links first) or completely railroaded form systems seem to work, but in reality often don't, and if you don't fall in one of the neatly compartimentalised problem boxes, you're sorely out of luck. And the back-end will never notice.

That cuts down on getting requests, sure, but it doesn't help the users and so doesn't make them any happier. Just count the number of clicks from start to finish navigating, say, google's problem resolution thing, trying to get to some way to submit a problem that is not in the standard answer boxes. The last few times I tried I got stuck in infinite loops.

There are a couple of instances where the bug and request handling works reasonably well. I've even seen functioning helpdesks. Usually because the people staffing them are a few notches above the regular cut, and they think really hard about reaching out and finding problems instead of making the annoying customer go away.

Give users an easy to leave feedback (1)

apcullen (2504324) | about a year ago | (#44249419)

I put a button in my software. Click it and a form pops up with a "describe what you were doing when a crash or bug happened, or make a suggestion for a new feature" type message. It also, behind the scenes, captured the state of the program when the button was pressed. That worked well. I got a bunch of new feature requests, as some good hints as to what the user was trying to do when things went south. YMMV

Help, I live on Earth! (1)

FuzzNugget (2840687) | about a year ago | (#44249589)

And it's not working!

Aactually yes... (1)

Charliemopps (1157495) | about a year ago | (#44249661)

Actually yes... I get very good bug reports from users. Luckily I did tech support for about 15 years before I got into development. So I had a lot of experience dealing with people that basically had no idea what they were doing. Keep in mind, I work in a corporate environment where what I create is consumed by a limited set of about 5k people.

1. Relationships: Where possible I get to know, personally, the people that will use my software. I can't know them all because there's thousands. But I can find key people, Managers, Seniors, etc... take them out to lunch, make them feel comfortable talking to me, and explaining the need for tickets rather than random emails etc...
2. When a strange problem arrives or I suspect such a problem may exist in some new software, I give them tools. Specifically a button that says "REPORT BUG!" that takes screenshots, dumps the contents of variables and datasets. If available, previous steps taken. Also the log files... and sends it all directly to me. Usually adding such a thing is pretty simple depending on what you're working in. C# and VB have all kinds of pre-built stuff that make this sort of thing super easy.
3. I write documentation on how to properly submit a bug. I make it very clear to people that are not computer savvy what to do. Down to "How to save the file" and "How to take a screenshot" I make it so even my mom could follow the instructions. Generic instructions like this may take you a day or so to write, but then you can just shoot them out to anyone having trouble.
4. Restate the issue. This is the classic "My computer doesn't work! *Is it plugged in?* "I can't see back there, the power is out" You have to know exactly what the customers real issue is. Listen to the client, write down what you hear as the problem, then restate that problem back to them using entirely different language. "My computer doesn't work! *So if I understand you correctly, you're calling me because you've hooked up your computer correctly, you've tried to turn it on, but it just hangs there?* "No! I want to pay my electric bill!"
5. Once you've fixed the problem, confirm with the user that it is in fact fixed. There's nothing worse than fixing something, closing the ticket then having the user come back 3 weeks later asking when you're going to get around to finishing. *You contacted me because your report was giving you incorrect data. We've found that in the original requirements there was a typo and this app should have included an average next to the new sale button. We've added that and now it appears the way you expect it to?* "Yes! It looks great thanks! Want to go get some lunch?" *Sure thing Tammy*

Good luck.
 

Simple. Respond to them. (1)

Fringe (6096) | about a year ago | (#44249769)

I am a developer. I write good bug reports. But when using a product I'm not working on, if the devs or the process seem out of touch, I don't tend to. If there's a crash report, I won't invest much because the seems to be zero investment back.

Whenever a bug is submitted, a real response... not just an automated mailer... should be sent within a day. Get more details if needed, provide an ETA. Otherwise, we're spitting in the wind, and it doesn't seem worth the effort.

Funnel (1)

QuietLagoon (813062) | about a year ago | (#44249771)

In one company where I worked, I was able to have the end users funnel all their bug reports through the company's internal education department. If the "bug" were actually a prevalent user error, the education department would note that and modify their internal courses to instruct the users on proper usage. If the"bug" were actually a programming problem, the bug reports we got from the education department were very helpful to resolving the problem.

Write it for someone else (1)

yorgo (595005) | about a year ago | (#44249795)

I just held a meeting yesterday with my entire team to discuss this very topic. Generally, I explained that the onus of successful communication lies with the giver (not the receiver). That is, if I want you to understand me, I must communicate in such a way that is understandable by you. (If I speak gibberish, I can't get upset if/when you don't understand me) I explained that submitting a bug report is simply a form of communication, and the the bug report submitter is the "giver" of the communication. Thus, if they want to be understood, they must ensure that their communication is understandable by the receiver. And, since they don't know who the receiver might be, they must make is understandable to the "lowest common denominator" receiver. I said, "If you write a bug report that your grandmother can understand, there is less possibility that it will be misunderstood". I explained that, "if you write a bug report...with the intent that is will be read and used by SOMEONE ELSE...there is a good chance you will write a good bug report." That said, I also implemented a very simple, auto-populate "bug report template" that helps guide and remind users what to enter (ex: "Description of bug, What I did to cause the bug, What I thought was supposed to happen, What actually happened, etc.).

Embed logging technology in your software (1)

time961 (618278) | about a year ago | (#44249841)

By this I mean that you should instrument the code with real, meaningful activity logging, not just some afterthought that grabs a stack trace and some state variables (although you'll want to have that data, too). If you instrument your code with logging that produces readily human-interpretable information about what's going on, the payback is huge, because it makes internal developers' lives easier, and it allows even first-level support folks to to a better job of triage and analysis. It's really important to make it meaningful to the human reader, not just "readable"--an XML representation full of hexadecimal doesn't cut it, it needs to include symbolic names.

Let the users see the logged data easily, if they ask for it, and maybe give them a single knob to turn that controls the level of logging. This will help technically sophisticated users give more useful reports, and it's really helpful in any sort of interactive problem resolution (OK, do X. Now read the last few log messages. Do any of them say BONK?).

It's really useful to include high-resolution time--both clock time and accumulated CPU time--in log messages. This is great for picking up weird performance problems, or tracking down timeouts that cause mysterious hangs. Depending on your architecture and implementation technology, other sorts of "ambient" data (memory usage, network statistics) can useful here, too.

There's a trade-off between logging by frameworks, mixins, macros, etc., and logging of specific events. The former approach gets comprehensive data, but it often can't provide enough contextual semantic information to be meaningful. The latter approach scatters logging ad-hoc throughout the code, so it's very hard to make any argument for comprehensiveness, but if done properly, it's spot-on for meaningful messages. Usually best to do some of each, and have good control knobs to select.

Logging can generate a lot of data, so it's important to be able to minimize that burden during routine operation (especially in deployed applications, where there should be a strict limit on the amount of space/time it takes up). But it's also useful (especially when it's configured to generate a lot of data) to have tools that allow efficient ad-hoc review and analysis--an XML tree view, maybe filtered with XSLT, can be easier than a giant text file.

In any complex system, logging is one of the very first things I recommend implementing. After the architecture is settled enough to know what will be some of the meaningful activities and objects to record, bolting in a high-efficiency, non-intrusive logging infrastructure is the very next step. Then comes business logic, user interface, and all the other stuff. Pays for itself many times over.

Long term breeding program (2)

mseeger (40923) | about a year ago | (#44249959)

I think the only chance is to create your own breed of users... May take some time ;-)

Ask for screenshots (0)

Anonymous Coward | about a year ago | (#44249983)

Give them a simple way to take screenshots of the problem step by step.

Create an Account (1)

Russ1642 (1087959) | about a year ago | (#44250167)

Force your users to create accounts at SuperDuperBugTrackingThingy.com to report anything. Then send them daily email updates from said tracking system. Also get your moderators to admonish any user that dares accidentally post an existing bug or posts in the wrong section of their clearly laid out bug tracking hierarchy. Or you could go full retard, like Google, and force people to use Google+ to do anything.

Build Better Error Handling (0)

Anonymous Coward | about a year ago | (#44250183)

My biggest beef is cryptic error messages. Fix that.

Yep (0)

Anonymous Coward | about a year ago | (#44250261)

Water-board them.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?