We've had a recent problem with potential and current customers finding old and outdated information on our discussion boards.  One option we had was to archive the discussion board each time we have a new release (probably the best idea), but we didn't do that unfortunately.  Our other option is to just erase all old topics from our database (not nice to Google and we don't want people to think we're hiding our warts). The third option is to leave the content up and figure out a way to really make sure people know the info they are about to see no longer applies to our current product (probably).  It took me about ten minutes to come up with a solution using the BugMonkey plugin, which allows you to insert arbitrary JavaScript and CSS into your FogBugz site.

You can see an example in this post about FogBugz 4.0.

You can view the code I used for the lightbox effect.

You can also download and view the javascript: sample.js (880.00 bytes)

In doing this I realized it would helpful if there was a systematic id system for text portions of the page (in this case, it was difficult for me to get the date of the topic, since I didn't want it to be applied to current topics). Definitely something to think about in the future...

In this video, Dan and Babak talk about how we got to FogBugz 7. 

(Click to watch the large version on YouTube).

We decided to add subcases
Customers have wanted hierarchy in FogBugz for years.  They wanted to break their cases up into subcases and add to-do lists.  They like things to nest.  Lots of other bug trackers try to satisfy these demands, and a long time ago we decided to make this a high priority for our next release.

How hard could it be?
It should've been a simple task.  Add subcases to FogBugz 7.  Users need the ability to break down their cases hierarchically or create simple to-do lists inside of their bugs.  Most people could code it up in a few hours, or maybe a caffeine-hazed weekend, right?

So why did we wait until FogBugz 7 to do this if people have been asking after it for years?  As it turns out doing it right took some time...as we've gotten used to when building a new feature.

Doing it right - The first stab
Like most things that go into FogBugz, we're highly concerned with getting it right.  Our features need to be intuitive, simple to use.  If we add too much complexity we risk becoming just another arcane project management system requiring an advanced degree in Ganttonomics to operate effectively.  

On the other hand if we made subcases too simple we knew that the whole implementation would be disappointing to users. 

One early design we considered was to nerf subcases by not making them full FogBugz cases.  Users would create little subtasks that were essentially one-level-deep lists within their bugs.  Wallah!  Task lists.  We get to pat ourselves on the back and tick off another "feature" on the giant feature matrix.  But we quickly realized we'd run into all kinds of complaints: "Why can't I tag my subtasks?", or "I need to assign these tasks to someone else, and I can't!"  Before you know it you'd be waiting for the next version to come out with all its grand promises: "FogBugz 8 -- now you can finally add a due date to your subtasks!"  We've seen such missteps made by others when new features aren’t fully integrated into the core of the product, and we knew this option would never be a winner.

Doing it right - Round 2
After we rejected the nerfed subcase option, our program manager produced a slick spec.

It was a great start, so naturally we immediately started to argue.  Everyone wanted to make a fantastic feature, and everyone had different ideas about how to do that.  So we went round and round...and round.  We finally settled on a design and implemented an initial version.  We showed it off as an internal demo.  Surprise!  We needed more and more changes until everyone inside the company was happy with what we had.  Then we ran usability tests with a couple FogBugz customers.  Lo and behold, we discovered some major problems with our display of subcases in the grid view.  Sometimes when sorting and grouping in the grid view a case belongs in more than one grouping.  For example, a case may be assigned to me and show up under the "Assigned to Ben Kamens" group, but it also belongs directly under its parent case, which is "Assigned to Joel Spolsky".  In those instances we were simply displaying the same case twice in the grid view under both groupings.  This basically caused people's brains to melt.

Doing it right - Round 3
We had to redesign again.  After that last usability test, I was 100% positive that showing a case twice in the grid view was a terrible mistake.  Luckily, Dan, our FogBugz PM, wasn't so sure; he came up with an excellent set of affordances to make the duplicate cases much clearer and to give users the option to just show all cases (including subcases) in a flat view.  He was sure we could do it right and he went to work on me.

We went round and around about this again, as the case below demonstrates (and trust me, this is just a portion of the back-and-forth).  There’s a lot of passion about these issues at Fog Creek.

I was eventually persuaded that we could show duplicates if we were very careful about how the display worked.  The next round of feedback showed that this was right, and the two views we built in were a big success.

Other challenges
Subcases also presented a purely technical challenge: We needed to query hierarchical case structures without slowing down FogBugz.  More accurately, we had to run fast hierarchical SQL queries (get me the children of case 5, and their children, and their children, ... ) in all three of our supported databases: MSSQL, MySQL, and Access.  The support for recursive queries in these three databases is varied at best, and nonexistent in one.  Can you guess which is which?

Turns out there's a pretty cool solution for this problem explained by Joe Celko.  Instead of attempting to maintain a bunch of parent/child relationships all over your database -- which would necessitate recursive SQL queries to find all the descendents of a node -- we mark each case with a "left" and "right" value calculated by traversing the tree depth-first and counting as we go.  A node's "left" value is set whenever it is first seen during traversal, and the "right" value is set when walking back up the tree away from the node.  A picture probably makes more sense:

How does this help?  Now we just ask for all the cases with a "left" value between 2 and 9 to find all of the descendents of B in one fast, indexed query.  Ancestors of G are found by asking for nodes with "left" less than 6 (G's own "left") and "right" greater than 6.  Works in all databases.  Greatly increases performance -- particularly when querying large hierarchies.

What we delivered
Waiting to add this feature was worth it. Initial customer reactions have been very positive, and we've even had people who had no real interest in subcases when they heard it was coming tell us that it's changed the way they use FogBugz. 

• We added a context menu to the grid view which allows you to very quickly add all your subcases right there.  This makes it super easy to set up a whole set of tasks and break them up into their parts without leaving the grid.
• The outline view lets users easily see their cases’ hierarchical relationships.
  
  
• We clearly mark subcases that exist but do not match your current filter or search.
• We've added auto-complete to the case view so you can make existing cases into subcases of the one being currently viewed by simply typing a case number or searching for words in its title.
• You have the option to resolve and/or close all subcases when resolving the parent case.
• Subcases are fully integrated with search, filters, and all standard FogBugz workflow.
  

That's the feature we fought so hard over.  So far the feedback has been uniformly good, and we think it's a keystone in our best release yet.  You should try it out and sign up for a free FogBugz 7 trial.
 

Daniel Root has posted a walkthrough on how he uses FogBugz 7 and Scrum.

"Every day of the Sprint, a very short meeting is held where the each team member says what they did yesterday, what they will do next, and if there's anything holding them up. If something is holding them up, it's up to the Scrum Master to make sure the problem gets resolved. At the end of the Sprint, the Team has a working product that is shown to the customer in a Sprint Review and/or deployed into production. Feedback is received and items added to the product backlog, and the process repeats until the project is complete. I'm sure true Scrum Masters will balk at some of this - we typically combine what would be a Sprint Review and Sprint Retrospective, and are fairly informal with the process. We don't call the meetings or people by their official scrum names- in fact most of our customers don't even know we're doing this to them!" 

Read More... 

FogBugz can be used for just about any process oriented activity.  Lots of our customers use it not just to track bugs, but also to do all of their customer support as well.  Problems or questions come in to your Inbox, and your sales or technical support team take care of them.  In conjunction with areas and due dates you get a really effective system with minimal setup effort.  That's one of the many ways we use FogBugz here at Fog Creek.

FogBugz is also used here to handle all of our job applications.  We get hundreds of them, especially during our recruiting for summer interns.  I can't even imagine trying to keep track of all of this in Outlook or something--it just sounds like a total nightmare.

What we do is simple, and it works extremely well.  Applications go to jobs@fogcreek.com, which feeds into the Inbox in a FogBugz install devoted specifically to recruiting.  If you already use FogBugz for project management or customer service, you could just make another mailbox for job applications. 

Our hiring process has been written about before and consists of the following steps: A resume review, a phone interview, a screen sharing interview, and several in-person interviews.  We use these steps to narrow the pool down to the best candidates, hopefully resulting in an offer from us to some scary good programmers.

Every application that comes into the jobs@fogcreek.com email gets an auto-reply, which is at least a little funny, and assures them that a real person will look at the email, asks them to make sure they have provided us with some important information, and also asks them to keep replying using this same email thread.  The last request is because the subject line number tells FogBugz to append any new emails to the existing case, and all of the relevant information is kept in one place.  This works without a hitch.

We take each phase of the interview outlined above and make a fixfor that maps onto it.  We've made, for example, Needs First Review, Needs Phone Interview, Needs Copilot Interview, Needs In Person Interview, and so on.

The case comes into jobs@ and we clean up the title so the case is easy to read (usually, position: person's name, in the case title), and then we move it through the process. The case is then passed off to developers to review.  Candidates who get high ratings are assigned to the Needs Phone Interview fixfor and we arrange a time to talk on the phone.

We even use the free-text fields in FogBugz to keep track of the resume ranking that we give, and we use the remaining field to keep track of the questions that developers have asked the candidates; this keeps us from asking a candidate the same questions in different interviews.

This describes the process for developer and intern candidates, but we hire other kinds of people here too, believe it or not. To keep all of these positions separate we've created Areas like QA, developer, intern (by year), sys admin, and so on.

Using the list view allows us to easily sort by area, or due date, or fixfor so it's easy to see if something is overdue, or if we got a new email from a candidate already in the system, or whether a developer is slacking on resume reviews because they've been too busy eating Fun Dip

Once we decide to bring someone in for a visit to our New York offices we assign the case over to our people who handle the travel arrangements and they pick up the thread.  We follow this all the way through to making offers, and helping with travel and moving arrangements.

We could collect resumes with a web form, but we like the low-barrier nature of just emailing to our jobs address.  Everyone has a resume, and they usually take the time to write a cover letter, so why make them paste all of that stuff into whatever form we'd come up with, which is different from whatever form everyone else comes up with?  It's just more overhead.

That's it.  Collect the resumes, and shepherd them through the process.  A case for each candidate, all the information you'll need right there in the case, and easy to sort and organize.  If you're using some other system for collecting and responding to resumes, give FogBugz a try for this purpose.  I predict you won't go back.

Using the FogBugz Output Accessory with SnagIt

The FogBugz Output is the easiest way to get screenshots into FogBugz.

Download FogBugz.snagacc (249.46 kb)

Configuring the FogBugz Output Accessory:

The only thing necessary to configure the output accessory is telling it the URL for your FogBugz site, so it knows where to submit the screenshots.

From the SnagIt Editor, go to the Send tab and click on the arrow below FogBugz. Choose Options from the menu.

Enter your FogBugz URL:

Capture the Screenshot with SnagIt:

SnagIt includes a huge number of options for capturing and editing images.

Send the Screenshot to FogBugz:

On the Send tab, click on the FogBugz icon to create a new case with the image:

If you are not already logged on to your FogBugz account using Internet Explorer, you will be prompted to log on.

Other Options

Use the Existing Case... menu item to send a screenshot to an already existing case instead of opening a new one.

Use the New Email menu item to send a screenshot as a new email message through FogBugz.

Use the Send Reply menu item to send the screenshot as the reply to an email message received through FogBugz.

Troubleshooting

The FogBugz Output Accessory always uses Microsoft Internet Explorer to transmit the screenshot to FogBugz, even if your preferred browser is set to something else. Therefore, Microsoft Internet Explorer needs to be setup so that it can reach the FogBugz server. If you are having trouble sending screenshots to FogBugz and use a different browser, try running Internet Explorer once, and ensure that it can reach the FogBugz server and get you logged on.

Note that once the screenshot has been transmitted, the FogBugz Output Accessory will launch your preferred browser so that you  can edit and submit the case with the attached screenshot.

Peter Kent of Peter Kent Consulting wrote a nice review of FogBugz, and all the different ways you might use it yourself.  Take a look!

Have you ever just needed to export a FogBugz filter to CSV to import into Excel or some other application and you really didn't want to figure out the API?  Well, John Januszczak from Meta Software just made that really easy for you.

BugzReport is an open source Windows desktop app that will export any FogBugz filter to CSV files.

In the next version of FogBugz, this action will just be one click, but right now you can do it with the current version using this awesome tool.

1. Create a shortcut to your screenshot.exe program under c:\program files\fogbugz\screenshot
2. Move the shortcut to your desktop
3. Right click the shortcut and choose "Properties..."
4. Add /picture to the end of the target - making it "C:\Program Files\FogBugz\Screenshot\screenshot.exe" /picture
5. Assign a hot key to the shortcut.
6. Drink a lemonade.

FogBugz 6.x will work fine on Windows 2008.  The only things you need to do are

1. Install IIS 7 (it doesn't come preinstalled) and check off the boxes for .NET/ASP/CGI/etc
   
   
   
2. Disable DEP by typing "bcdedit.exe /set {current} nx AlwaysOff" on a command prompt. And then make sure you reboot afterwards.
   
   
   

I have a bit of a confession to make.  I spend a lot of time interacting with customers (which I'm told is a bit out of character for the president of the company) but I enjoy getting feedback from them and it helps me know where we need to focus our efforts.  We get some requests over and over again and while to the end user they may seem very simple to implement, the reality is far from that.  But that wasn't going to stop me from getting a feature out that I really wanted customers to have in this latest release (coming to On Demand later this week).

One request that we get fairly often is the ability to customize the look of different parts of FogBugz, particularly the logo.  It probably makes the kiwi a little sad, but I understand ... no hard feelings.  The only issue is that FogBugz is not the same application it used to be when I used to write code for it in version 2.0 and 3.0.  It has lambda functions, code generators, ajax requests;  which is fine for our brilliant developers but not for me and my limited IQ... one change here can affect a bunch of things over there that you never expected.

I had a bit of free time and I thought, "How hard could it be to let people upload a new image for the logo?"  It turns out, in this case it's pretty complicated.  To upload files, a form needs to have a certain encoding: multipart/form-data.  In php and asp, it's not trivial to decode this file upload, and in asp in particular it means you have to treat the rest of the form elements differently than you would have if it was a normal form post.  We do this for cases currently, but it means I couldn't just throw a File Upload input in an html form on the Site Configuration screen.  Also, storing files in the database requires a special table that will hold binary blob data.  We already have this for uploaded Attachments in FogBugz.  And if we're going to be serving a file from the database, I had to make sure the browser would cache it for a long time, but still download a new one if an admin decided to change it.  It just meant my tiny little code change was growing into a bigger code change, which meant it was unlikely to get done because of the amount of effort it would take.

So in the latest minor version we're about to push out, I piggybacked my feature on the already existing File Upload mechanism.  I protected it so users' couldn't just mine for any old attachment, and I made it so when you change the logo, your browser knows to download a new one.  Unfortunately the user experience is, well, a bit clunky.  You have to make a case, add your logo, and then copy the link for the logo to the site settings  -- rather than just clicking "Browse..." and uploading a new file on the Site page itself.  Since this isn't a feature that would get used daily, or even monthly, I'm hoping I get some slack for my albeit strange design and that people are happy to use it.  

An email from a customer who had posted a job, received no response, and then decided to run the add for an additional 3 weeks: 

Success!

We hired someone we got from the Joel board, and our second best candidate also found us there.

Thank you!

Cash that proverbial check.

Best,

Larry 

 And another email we received about Fog Creek Copilot:

Hi Guys,

I'd like to thank you very much for helping solve a very important customer's problem.

As a long time Fogbugz user I had high expectations of CoPilot, all of which were met.

I had concerns about how difficult it would be for me to connect to my customer, but all was seamless.  I managed to solve their problem in 2 minutes instead of the 30 minutes of phone calls it would have taken previously.

A very happy customer,
 
Byron 

Fog Creek Software has a bunch of great job openings right now. All are based out of our offices in New York City.

• Software developer
• Sales manager
• Support engineer
• System administrator
• Intern in software development
• Software Management Training Program

In the early part of this year, I read Joel's 7 Steps to remarkable customer service. The piece resonated with me, and it was one of the reasons that I applied to the SMTP program. Customer service in the world of technology is, generally speaking, an embarrassing and dehumanizing process. Here was a person who believed that there was a better way to do it.

Shortly after joining the company, I asked the question "Why do we give this information away freely? Aren't we concerned that our competitors are bound to read it, see the wisdom of it, and emulate it?" At that point, I had about 4 weeks of customer service duty under my belt and was confident that this model could be scaled and replicated. Now, after 6 months and lots of conversations with customers, I understand why it is to our advantage to let people know that this is the way we do things.

It is hard work.

Real customer service is emotional labor. You have to dance between being truly empathetic to a frustrated customer's problem and self preserving as a customer, pushed beyond the limits of human endurance, takes out their frustrations on you directly. The former is the norm and the latter the exception, but both efforts take a lot of energy. Add to that the fact that the problems I am asked to solve are frequently subtly complex technical issues, and I am spent at the end of the day. The payback comes in the form of a tremendous sense of satisfaction from seeing Joel's suggestions work to make not just satisfied but fanatical customers.

The problem is, I honestly don't think most of the people that apply for customer service jobs could do it. Either they don't have the people skills, but are excellent technically, or they don't have the technical skills. This is not to say that I am a phenom, by any means. It is proof positive of the draw of the promised career advancement once the customer service stint is over.

I am willing and motivated to work hard because these are the same customers that I hope to be serving as I move on to QA and Marketing and, eventually, to management. Understanding them, and their needs, gives me the information I need to make decisions and trades-offs about the products on which they rely. If you ask most customer service people what they do, I bet they would say "I answer email and telephone calls". Customer advocacy is my job. It is the best way to keep customers happy and continue to increase our revenue

You have to get the environment right.

To get people motivated and give them the tools they need to do the job of customer management takes real effort. While Joel's steps are conveniently broken up to make them more understandable, combined they create the environment necessary to make my daily efforts possible. The entire company is oriented toward the customer. We are constantly evaluating how what we do and what we say will affect our customers.

This is hard to believe for some customers because they have been asking for this one feature (or that one) for 2 years, and we haven't implemented it. Although it is easy to imagine us in our ivory tower laughing with scorn at your feature request, I can honestly say that we agonize over our decisions as to which features to implement when. We honestly feel badly about not getting to your suggestion, but we can't cloister ourselves for 10 years writing the next version, so we need to choose.

Our incredibly lenient return policy allows me the freedom to say to someone "Try it, if you don't like it you get your money back immediately, no questions asked" and "I can't recommend that you buy FogBugz because it isn't going to do everything you want" and "I am really sorry that we couldn't get you connected, here is your money back and a free pass for your next connection". All of this is intended to show that the second reason we aren't at risk is that it is almost impossible to replicate this environment without tremendous effort, and true belief that it is worth it.

By telling customers that this is how we do business, and actually sticking to it, we make our customers confident in our ability to make them happy. We get more risk takers and advocates that push our products into markets where they might otherwise go unnoticed. And my life is better because when customers call or email, they (mostly) treat me like a human being that wants to help them, instead of their worst enemy.

We aren't at risk at all; we have a distinct advantage, a differentiator. While other service organizations understand that these are good ideas, they aren't able to implement them (the environment isn't right) or they won't implement them (don't want to do the hard work). In the rare cases that I come across one that is able and willing, dealing with the company is such a pleasant departure that I find myself liking them, even if they are one of our competitors.