CaseDetective 1.1.2 is just a little update to make sure Attachments are sync’d before Bugs and BugEvents to ensure referential consistency, particularly if the app is quit before the sync completes. This was broken by today’s v1.1.1 release.

Should have known better than to release software on the 6th day of the 6 month in the year 06! 🙂

Maybe the fact that this is build 222 will help?

CaseDetective 1.1 has finally hit the server, and is now ready for download from it’s shiny new website.

I was tempted to call this release “2.0” as it’s changed so much from 1.0.1, but in the end I decided 1.1 felt more natural and true to my intentions.

This release took a lot longer than planned, mainly due to the huge change in the way cases are retrieved from the server for faster filter browsing.

But I’ve “sneak peeked” that before on this here blog, so I won’t go over that again, or anything else that I’ve already written about.

What I can write about for the first time is the Preview Pane, an area under the list of cases that shows details of the currently selected case and the history of comments, emails and changes that have occurred. In fact, I’m not even going to write about it, I’ll just show you a picture of what you can get if you right-click on it and save it as an image…

Current users of CaseDetective should start to see update notices the next day they start CaseDetective (if they have automatic updates turned on) or the next time they “Check for update”.

I’ll be sending out a short newsletter in the not too distant future too.

CaseDetective 1.1 for FogBugz is a free update for all current users. New users can buy CaseDetective for $69, and there is a free 30 day usage trial available.

CaseDetective for FogBugz 1.1 is done, finished, complete … almost. Just need to get the documentation done.

It’s always the last thing to be done, we developers always put it off to the last moment and generally see it as that horrid task sent by the devil to torment us.

Except this time I’m not minding it too much for some reason.

Maybe it’s because I’ve decided to really shake up the documentation and website this time round, last time it was a little half hearted and I’m feeling I need to make a big push this time to get a much better quality set of docs there.

Since releasing CaseDetective last year I’ve had a fair few support requests that really shouldn’t have been there, documentation should have nipped them in the bud. Whether that be information on the website for prospective downloaders or in the help docs for those looking to get a little more from CaseDetective. Obviously my docs just weren’t up to scratch.

At first I’m just getting the basic documentation framework back into shape before private beta as I’m changing the way I produce them a little, it won’t be anywhere near complete but should give an idea as to the format (placeholders will abound).

Originally I authored my documentation and CaseDetective website in separate RapidWeaver files and then processed the documentation output through HelpLogic to get the final help files and separate docs website. There are pros and cons to doing this.

On the plus side it was easy to set up the documentation file so that it didn’t use any index.html files, HelpLogic doesn’t allow them as they conflict with files it has to create. It also meant I could have a nice docs website that looked and performed just like a normal help file, with searching, contents, index and everything.

On the minus side is the fact that I was maintaining two separate files which shared a lot of the same information, such as support contacts, features overview etc. Also, that separate docs website may be searchable by itself, but not from Google and other search engines as it uses frames, so does not contribute much to my marketing effort (when I actually start to do some that is). The separate docs site also doesn’t have my CaseDetective theme, it’s totally different so doesn’t look part of the main CaseDetective website. Both the searching and not being integrated into the main site are potentially big hindrances to getting free marketing from the content (when it improves) and looking professional.

So I’m now using one RapidWeaver file for my CaseDetective website and just rejigging it so that I only have one index.html, the main one which would never be included in the help files anyway.

My (new) website will have fully integrated documentation using the same theme as the rest of the site and will of course be searchable by search engines. And when building my in-application help files I simply switch the theme to a plain theme I’ve created and extract to a folder that HelpLogic will pick up from. Then I just delete the index.html file and it’s associated resource files and use HelpLogic to reformat everything for Windows and Mac help formats. A quick compile to CHM format with the free Windows HTMLHelp Studio and index the Mac OS X Help Book with the free Help Indexer and we’re ready to build the Windows setup file and Mac disk image. It takes much less time than it did to write this paragraph, honest!

Well, I guess I should get back to it, those private beta testers must be chomping at the bit by now, desperate to get their hands on CaseDetective 1.1b1!

So far the sneak peeks for CaseDetective 1.1 haven’t been all that enthralling, even I am able to admit that the features I’ve shown aren’t that big a deal to most users of CaseDetective and FogBugz.

This one may turn a few heads though, CaseDetective for FogBugz 1.1 will include the ability to view some “potted” graphs, just like this one:

The above graph was grabbed from the new “Overview” pane, which includes the previously sneak peeked Last 50 Events list. To be able to include graphs of statistics from FogBugz in your reports, all you have to do is select an appropriate filter and pick the type of graph you want, then simply copy and paste the graph into your report. It’s as simple as 1-2-3!

And as you can see from the above screenshot (click it for a better view), when you hover your cursor over a “node” you get a little yellow pop-up with a bit of info about it, such as the number of cases (Y value).

For some people this could be a real time saver, as it’s a very quick way of finding out how many of your FogBugz Cases are in a particular Priority, Status, Release and so on, there are quite a few fields you can graph:

And of course, you need to be able to see when it was that you had that sudden spike in feature requests opened, resolved, closed or last updated:

Being able to quickly see patterns in your FogBugz data through graphs and charts in CaseDetective for FogBugz should hopefully help a lot people get through their day that little bit quicker when it comes to getting those reports out.

This post was originally a guest post for the Fog Creek Blog, but I’m re-posting it here for completeness with permission from Michael.

There’s a neat little new feature hidden away in FogBugz 5 (currently in beta) that I think a lot of people will find useful (and not just because I asked for it), HTML anchors on displayed bug events.

I guess I should explain why I asked for them and why I think you’ll find them useful…

A few months ago there was a feature request on the FogBugz discussion forum that I thought was pretty good, so I nicked it for CaseDetective (thanks Sam Chrisp)!

The feature request was for a “Recent Activity List”, basically a listing of the last X number of edits and comment events so that the FogBugz user could see what has recently happened, and then click through to any Case that’s of interest. The feature request even included a picture of the list that the user had created for themselves by modifying the FogBugz code.

I liked the idea and felt it would be useful as long as you could click on an event line in CaseDetective and go directly to the FogBugz edit entry in the Case view page without having to scroll down the page to it. There was one snag though, FogBugz 4 didn’t have any HTML anchors on each of the entries in the view page so CaseDetective couldn’t construct a URL to go directly to the entry. Darn!

So I fired off a quick email to Michael (Pryor, I think you all know who he is 🙂 ) asking whether he’d consider adding anchors to the view pages in FogBugz so that anyone could construct a URL to go directly to the event. Michael said he’d pass it on to the development team for appraisal.

The announced features for FogBugz 5 didn’t mention anchors so I thought I’d missed the boat and would have to wait a little while before implementing my Recent Events list. However, while playing with the FB5 beta late one night (make that early one morning, just couldn’t sleep until I found out everything that was new) I checked the HTML source for the Case View page and there they were, BugEvent anchors. Yeehaa!

Here’s the deal, every bug event that is displayed in a Case has an anchor in it’s header, something like “<a name=”BugEvent.9969″>”.

This means you can send someone directly to a comment or edit with a URL such as:

http://server.example.com/fogbugz/default.php?pg=pgEditBug&command=view&ixBug=2469#BugEvent.9969

or the even simpler:

http://server.example.com/fogbugz/?2469#BugEvent.9969

As long as the URL ends with a “#” followed by the anchor’s name, you should be good to go.

This kind of thing is very useful when you want to point someone to a particular comment or edit, instead of having to say:

“Please have a look at the comment dated 03/04/2006 10:20:30 made by John Doe in case 2469”

you can say:

“Please look at this comment: <link>” and past in a direct link to the comment.

Of course, it’s helped me a lot as it meant CaseDetective could acquire the Recent Events list I wanted to implement. Double click an event…

… and you’ll be taken directly to it in your default browser:

This event list will make up the bottom half of CaseDetective 1.1s new “Overview” view, which I’ll discuss a little more on my blog soon.

CaseDetective 1.1 is still in development, but we’re working hard on getting it into your hands as soon as possible. Stay tuned for more updates as we get closer to release.

In FogBugz there is this concept of a Project Area. Areas are usually something like “Code”, “Documentation”, “User Interface” and so on, a way of categorizing a Bug, Feature or Inquiry so that the correct person can pick it up. They are very useful, a great way compartmentalizing you Cases for better resource and time management.

The problem is, these Areas are children of a Project, so it’s impossible to create a filter in FogBugz that captures all cases that are in an Area regardless of the Project they are in, for example; all Cases related to “Code”. This is a real shame, as many people use Areas for all kinds of things, and would love to see all cases that have the same Area. Some people think of Areas as a kind of tag.

In CaseDetective 1.1 for FogBugz we’ve opened up Areas a little by giving you a “Open cases by Area” summary filter, allowing you to see all open Cases in each of your Areas, regardless of the Project they’re in.

But, if you then need to drill down to find out which Projects those Cases are in, you can.

Some way of seeing all cases in an Area name without having to select a Project has been one of the most requested features I’ve seen, and something I’ve long wanted myself.

CaseDetective 1.1 is still in development, but we’re working hard on getting it into your hands as soon as possible. Stay tuned for more updates as we get closer to release.