Feature request #208: In-application bug reporting

Comments

1. Greg Hurrell 2005-05-03T09:30:08Z

   Thanks for the report. I think you make some good points. It's true that Bugzilla is developer-friendly and that many users find it intimidating (you though seem to be doing just fine!).

   The Hardware and OS fields aren't much use, I know. Bugzilla picks reasonable defaults for these based on your browser, but the truth is you can ignore them (it's not possible to turn them off without hacking Bugzilla, and I prefer to keep it as standard as possible).

   The main strengths of Bugzilla as I see them are:

   1. Public, so users can search for prior reports as well as check back and see the progress on issues they have reported. It also facilitates collaboration.

   2. Extremely powerful, especially in terms of searching, which means that I can find exactly what I am looking for very quickly (which means I get bugs fixed quicker!). It is so powerful that I now use Bugzilla to maintain my "TODO" lists rather than keeping private documents "in house". It takes 20% longer to file the report in bugzilla, but once it's in there I know it won't be overlooked.

   3. Widely used in the industry by lots of high-profile projects. In theory this means that once you know how to use Bugzilla at any one site, you know how to use it at any of the others.

   The main problem with the Safari-style bug reporting is that it isn't hooked up to a public database, so it encourages duplicate bug reports. Because I work alone it's a fairly high priority for me to minimize duplicate bug reports (and even with a searchable public database I still get a fair few duplicates). (On a tangential side note, I do wonder if anyone at Apple actually reads those reports...)

   I do recognize that having to have an account and login in order to file a bug report makes it a little harder to file a bug report. I do my best to make it easy by putting a link to the bug database in the navigation bar. I also hope that users are using the auto-form-fill features of their browsers to make it easy to log in. The truth is that the "barrier to entry" when it comes to filing bugs probably means that the people who do file bug reports end up filing ones that are of better quality; the signal to noise ratio is pretty good (which once again means things get fixed faster, and that's my number one goal).

   If you look back at some of the bugs that have been closed in this database you'll see that often there was a degree of collaboration between users ("me too", "worked for me", "didn't work for me", "can you try this?") that wouldn't otherwise be possible without a public database like this.

   Synergy Advance includes a crash reporter framework (WODebug) that allows users to send crash reports if something goes wrong, so I've already got part support for what you're asking. There's also the contact page and the support tickets page that many people use to file bug reports. Of course, I would prefer people to use the bugs database for bugs as I honestly do believe that it leads to stuff getting fixed quicker (so much so that if someone sends me a feature request by email I usually come here and paste their email into a new bug report).

   I must admit that I'm not all that keen on going as far as you suggest and adding an in-app bug report window, but I'll leave this bug report open so that others can leave there comments on it and vote for it (see how great bugzilla is?!)...

   Thanks for the input!

2. Nigel 2005-05-03T18:22:29Z

   I see your points, and I understand why you want to keep using it. I suppose that personally, learning how to use Bugzilla is a useful skill for me. I can learn to live with it.

   I wish there was a way to list all the bugs in the database, showing the newest first, so I could keep track of what's going on when I log in to report a bug. Correction: I'm sure there's a way, but I wish there was an obvious way. I find the page you get when you first log in is baffling because it's not at all obvious what you need to do. I think it would be useful if the default view showed the newest 10 or so bugs, similar to the view you find when checking out the forums.

3. Greg Hurrell 2005-05-03T18:56:18Z

   To get the list of all bugs, newest first, click on the "Search page" link that appears at the top (and bottom) of this page:

   https://wincent.dev/a/support/bugs/query.cgi

   Just click "Search" on the page that shows and it will show all open bugs for all products. If you want to confine your search to a single product then choose the product from the popup menu.

   Bugs are sorted by ID number, so the oldest bugs will appear first in the resulting list so you have to look at the list from the bottom if you want to see the latest.

   You can save this search (or any other) by using the "Remember search as" button at the bottom of the list. Pick a name for it, like "All bugs", and the saved search will appear on the footer of every page when you are logged in.

   I can edit the front page and change/add links. It is possible to put some useful saved searches on there.

4. Greg Hurrell 2006-07-05T02:05:27Z

   Changing assignment to reflect my new email address.

   https://wincent.dev/a/news/archives/2006/05/change_of_email.php

5. Greg Hurrell 2008-04-27T12:13:02Z

   Ok, so this issue is now in part addressed by the Rails rewrite of the site and the end of Bugzilla.

   I'm changing the summary from:

   • REQUEST: User-friendly bug reporting (was: Bug reporting is difficult)

   To:

   • In-application bug reporting

   To better match the remaining portion of this ticket. My position on this has changed a bit since nearly 3 years ago when this ticket was opened; despite the risk of duplicate tickets I now actually think that in-application bug reporting is actually a good thing. There is some overhead involved but I think it will lead to problems getting found and fixed sooner.

   The new issue tracker is simple enough to use that I could even just embed it in a WebKit view in the application (either the actually support ticket page itself, or just a lightweight HTML form that worked with the remote webserver using a RESTful resource model).

6. Greg Hurrell 2009-04-07T03:44:33Z

   Ok, I'm going to change the product assignment for this issue. The website is already ready to accept new issue reports via an XML POST request, so the work needs to be done in the WODebug framework to provide a client-side UI for this.

7. Greg Hurrell 2009-04-07T03:45:03Z

   Product changed:

   • From: wincent.dev
   • To: WODebug

8. Greg Hurrell 2009-04-07T04:04:16Z

   See also ticket #448, which is about getting WODebug to submit crash reports directly to the issue tracker rather than send them via email.

Add a comment

Comments are now closed for this issue.