Bug tracking tools can be fairly simple from a programming perspective. Which is probably why there are hundreds of them out there all doing an equally OK job. But, if you take a look at mostbugtrackerinterfaces, they look uncomfortable. They look like a bunch of HTML form elements all got together at some stiff HTML form party thrown by [TEXTAREA]. Yep, textarea's the one that owns that sweet 30-column [TABLE] over in the Hamptons. Anyhoos...Good bug tracking interfaces should be a little more personable and a lot more understanding of what the hell's actually going on. I'm appalled by the lack of good UI design in bug trackers when there seems to be a nice web 2.0-y thoughtfulness to every other kind of self-help web-based software known to man these days.So, I decided to build my own.I'm currently on the home stretch of developing a bug tracking tool for WAM that we have every intention of releasing to the public in the first half of 2009. And, I've put together a few pointers on what I think makes a better bug tracking interface.Differentiating the finders from the fixersAlmost exclusively, you are either a bug finder or a bug fixer. In our line of work, our clients tend to be bug finders and we tend to be the bug fixers. Other companies have internal teams of bug finders (a.k.a. QA testers). The problem with most bug trackers is that there's no differentiation between finders and fixers. Our bug tracking tool will make this differentiation. A typical bug finder's overview screen will show all bugs that are ready for his review. Here, I'm standing in as a bug finder. I can easily see that there are a few bugs I better confirm are fixed.A bug fixer's overview screen will look slightly different. He won't have any bugs to review. After all, only the person who finds the bug should be allowed to say whether it's been fixed (I completely agree with Joel on that). Instead, he's concerned with two other things: How many bugs are being reviewed, and how many came back with an uh-oh.There are all sorts of other sets of capabilities differentiated by finders v. fixers in this application. And, it's important to keep this distinction in mind instead of keeping things free and undiscriminating between those who findeth and those who fixeth.Telling you what should happen nextOne of the great advantages of developing a bug tracking system is that bugs inherently have a direction. There is always a next step. When a finder assigns a bug, the fixer should begin working on it. When the fixer needs more info, the finder must provide it. When a fixer thinks its fixed, the finder must confirm it. One of the disadvantages is that people aren't very proactive by nature, especially when it comes to something as oh-so-fun as solving bugs. A good bug tracking system needs to tailor the messaging so it's clear what the next step should be.Here, a bug's been set to the "Ready for Review" status. Instead of finding an unassuming label that says "Ready for Review", our tool tells the fixer to do something. Say it's fixed or not fixed and give a reason why.Showing you what's happened since last timeAll bug trackers keep some form of history. But, I've seen two problems. First, some bug trackers differentiate bug history by action type. Comments have a comments section, status changes have a status change section, and re-assignments in a re-assignments section. In my mental model, this is counterproductive. To me, all of these events need to be in one section, sorted by date. A comment has a different context when I know it happened right after this status change or right before it was re-assigned to someone else. Fortunately, though, many bug trackers do combine everything.However, very few actually keep track of when you last visited the bug. I've found myself having to re-read the last week's worth of history to figure out what I haven't actually read yet. In our system, we highlight all history since the last time you viewed that bug. This way, you immediately know what chatter is really new to you.So that's it. Three simple points of focus that better orient bug finders and bug fixers who, frankly, would rather be doing something else. What do you think?
