We've posted new videos on our Fog Creek video page. 

Earlier this summer we decided to experiment with some new ways of getting out information about FogBugz and Kiln, and since we had the talented Lerone Wilson already doing some video work for us, making product videos was an easy choice.

A lot of the product videos were--what shall we say?--a little on the boring side.  We wanted to make something a little better than you usually see and avoid all the usual mistakes, like having your bored product manager mumble his lines through his nose.

We ran through our actor options here, but most of us sounded like Keanu Reeves, only dead.

Since we're in New York we put out a call for actors and got dozens of submissions from some really talented people, and found a guy we liked.  Only later did we discover that he's a veteran of the Onion News Network. (NSFW - Swearing).  He was a lot of fun to work with.

That's it really.  A few days of filming and we had video covering all of the major parts of FogBugz and our new product Kiln.  We had a half day of time left that we had paid for so we added some "Howto" videos describing common tasks in FogBugz.

We hope these are useful!  We'd love to hear what you think, and if there are other topics you would like us to cover, let us know.

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.

FogFanz has an interesting article up about using FogBugz as a Getting Things Done (GTD) tool.

It's a great topic, and one that we talk about here a lot.

A growing number of Fog Creek employees use FogBugz as a GTD tool.  Rich, the fellow in charge of our customer support efforts, has designed his workday around a series of lists in FogBugz that give him the next things he needs to do.  Filters are the means of constructing those lists.

Since he's not in control of the volume of customer email he gets, our Inbox for customer service becomes his defining task list for the day.  Rich and the support team work through the Inbox first. He takes care of these cases in the order in which they arrive, and rigidly enforces the "no cherry-picking" rule because cherry picking makes the whole system break down.  You spend (waste) time thinking about what to do with a case several times over, avoid addressing your weak spots, and inevitably answer the customer who tells you how great you are and wait to deal with the one who has the malignant Mono mystery Unix install failure.

To Rich, every case that comes into the Inbox is an opportunity to make that thing never happen again, or at least reduce how often it happens.  He spawns off a case in the Fix It Twice area so that it ends up in a trusted system, one of the keys of GTD: You have to capture everything.  These are the cases that make those Inbox problems go away forever.  These are the cases that will reduce your support volume.  These are the cases that will make support staff and customers happier.

Joel has talked about using Five Whys and Fix it Twice on his blog, and we've even been inspired by these guys.  Here at Fog Creek Fix it Twice has become a bit of an OCD obsession.  Rich has helped us make this less of an ad hoc system.

Anytime there are spare cycles Fix it Twice cases get attention, so when the Inbox is done Rich digs into the Fix it Twice list.  This is where the real magic happens, and where Rich has brilliantly gotten support off the treadmill of trying to keep up with more and more support requests.  This is where he gets to think creatively about how to fix problems permanently, which also happens to be a nice break from the routine of daily support, and turns support into a strategic role--a thinking-person's job--and a role less prone to burn out.

To us, your GTD "inbox" is NOT the same as your FogBugz Inbox.  Your GTD inbox is the Fix it Twice area.  The cases in Fix it Twice are the things you will get done, the things that will reduce your support load.

The progression from processing the Inbox to processing Fix It Twice is as close as we've ever gotten to implementing GTD's idea of contexts in a real way.  Effectively, it boils down to Inbox is @reactive, and Fix it Twice is @strategic.

Rich has a few extra steps (that he may write about), and has put a lot of thought into this FogBugz/GTD system, making it simple to follow, but powerfully effective in reducing the volume of support problems we encounter.

The point is that he has lists in FogBugz that help him to organize his day's work, and that this melding of GTD thinking with strategic customer service thinking has helped us move away from running to catch up, to more effectively driving the direction of support efforts.  If you have a growing customer base and don't make Fix it Twice part of your life, you'll always be trying to run a little faster on a merciless treadmill.  That is until something breaks badly--your support staff gets burned out, or your customers become so sick of your inability to help them that they burn you in effigy (or in modern terms, say nasty things about you on Twitter).

There are lots of tools to help you follow GTD, but FogBugz can definitely work in that role.  It can work as a personal system, or you can make it work for strategic customer service.
 

We have a fan blog!  We didn't start it--I mean, we're fans of ourselves, but that might be a bit much.  Instead it's kept by a longtime user of FogBugz who has a background in usability testing, and in a recent post he gives FogBugz a theoretical makeover.

He proposes some interesting ideas that are worth a look.  I especially like that he appreciates some of the hard design decisions that go into keeping an interface simple and easy to use, and yet still providing all the functionality customers want.  For more in that vein, you might also take a look at his post on possible FogBugz 7 features (just remember those aren't our promises!).

Drop by the blog and let him know what you think of his FogBugz design ideas.

Rick Minerich has a great little post about how he uses Executor to get to his FogBugz cases quickly.  Executor is a flexible tool that adds lots of functionality to the normal Windows run command window.

Call up Executor by hitting Windows-z.  To set Executor up to go directly to FogBugz you'll need to set up a keyword.  Launch Executor and right-click on it to choose "add keyword" from the menu.  Or you can type in "-key" into the command box to get to the keyword interface.  Once there right-click where the keywords are listed and select "Add..."  Choose a title for it, and in the Command box directly below the keyword paste the url of the case or filter you want to be able to go to. 

This can be done even more quickly by typing "-a [name of command]" to have Executor take you directly to the keyword page with the keyword title already filled in.  There are lots of nicely thought out touches like this in Executor.

I set up a filter in FogBugz that shows me "All open cases assigned to me."  I ran the filter, copied the url, and then pasted that into the command line of the keyword interface as described above.  I named it FBME (Executor doesn't like spaces in the keyword).  Now I can hit Windows-z and then type FBME and it immediately runs that filter and shows me the cases I want.  You could do this with any filter or even with specific cases.

I've scarcely looked at all the options Executor has, but there are a lot of them.  I've had Executor setup to work with my FogBugz install for about ten minutes and I already love it!

Matt Johnson, who works for a company that uses FogBugz, unleashed his design skills on FogBugz to make an alternative FogBugz interface that you can take a look at and try.  Instructions on what you'll need to install are on his site. 

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!

Our very own Jude Allred, one of our interns from last summer, uses iGoogle to keep track of the many tasks he has on his plate.  He came up with a nice way to make FogBugz cases appear on his iGoogle page for easy viewing.  

When you try FogBugz On Demand you’re asked to choose a subdomain for your account which will result in a url like this: bigcompany.fogbugz.com.

Ian M. Jones, frequent contributor on the Fog Creek discussion forums, wrote in to customer support because he was trying to set a CNAME alias in his DNS file so that support.bigcompany.com would direct to his On Demand account, which, in our example, would be bigcomapny.fogbugz.com.  In theory this should work, but it kept failing.

In Ian’s case he wanted to do this so RBScoutSubmit would still work without the need to rewrite some of his existing code.  Most people probably don’t have this specific need, but you might want to do this so you could direct your customers to your On Demand account but display a different url through the whole transaction.

After some investigating I discovered that we have two problems both of which we intend to fix.  As is often the case, though, there are a lot more pressing things to attend to at the moment.  The first problem is that our system doesn’t know how to associate your custom subdomain to your existing On Demand account.  This is a trivial thing to fix.  More problematic is the fact that we serve everything over https.  This isn’t a problem itself--it’s good--but we have an ssl cert for the whole fogbugz.com domain, and not for any other domains that might be directing to the fogbugz.com domain.  We probably don’t want to get into the business of managing ssl certs for other people so they can do this redirect, although that would be one way to solve the problem.

Meanwhile Michael Gorsuch, our sys admin, had been thinking over night about using the Apache ProxyPass directive as a work around.  After a little experimenting he got it to work. 

You need to make sure that both mod_proxy and mod_ssl are installed on your Apache server.  Then create a new virtual server that proxies everything from itself to your On Demand service.  Like this:

<VirtualHost *:80>

  ServerName support.yourdomain.com

  ServerAdmin webmaster@localhost

        SSLProxyEngine on

        ProxyPass / https://youraccount.fogbugz.com/

        ProxyPassReverse / https://youraccount.fogbugz.com/

        ErrorLog /var/log/apache2/error.log

        LogLevel warn

        CustomLog /var/log/apache2/access.log combined

        ServerSignature On

</VirtualHost>

Then restart Apache, and you should be all set.

Obviously with a simple redirect on IIS or Apache you would go from support.bigcompany.com to bigcompany.fogbugz.com.  With the ProxyPass directive in place you can now send your customers to your On Demand account all the while displaying the url support.bigcompany.com

My last post detailed how to isolate the code for a publicly available project so it could be called from its own url.  There are a number of reasons why you might want to separate your public projects in different submission pages.  You might have a number of public projects, but only want certain customers to have access to a single project.  You might want to change the look of the submission page to something that matches your corporate look.  Or maybe you just love to play with html. 

I pulled out (almost) everything that wasn’t essential in the code that follows (aside from a little css since I’m going for simple, not hideously ugly).  It keeps the forms, input tags, the attach feature, labels, and the buttons, and that’s it.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

    <head>

        <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

        <title>FogBugz</title>

        <style type="text/css">

            label { float:left; font-weight: bold; width: 100px; text-align: right; }

            input, textarea { width: 500px; }

            select{ width: 504px; *width: 506px; }

            div#buttons { padding-left: 250px; }

            #Button_OKEdit, #Button_CancelEdit { width: 100px; }

        </style>

    </head>

    <body>

        <form action="default.asp?pre=preSubmitBug" method="post" enctype="multipart/form-data"

            name="formWithProject" style="display: inline;">

            <input type="hidden" name="command" value="new" />

            <input type="hidden" name="dtTimeStamp" value="7/18/2007 11:55:36 AM" />

            <input type="hidden" name="fPublic" value="1" />

            <label for="sTitle">Title:</label>

            <input type="text" maxlength="128" name="sTitle" id="sTitle" value="" /><br />

            <label for="ixProject">Project:</label>

            <select name="ixProject" id="ixProject">

                <option value="4">Ray Gun</option>

            </select><br />

            <label for="ixArea">Area:</label>

            <select name="ixArea" id="ixArea">

                <option value="28">Ray Gun: cool leather holster </option>

            </select>

            <br />

            <label for="sCustomerEmail">Email:</label>

            <input type="text" maxlength="80" name="sCustomerEmail" id="sCustomerEmail" value="" /><br />

            <label for="sVersion">Version:</label>

            <input type="text" maxlength="40" name="sVersion" id="sVersion" value="" /><br />

            <label for="sComputer">Computer:</label>

            <input type="text" maxlength="80" name="sComputer" id="sComputer" value="" /><br />

            <label for="sEvent">Message:</label>

            <textarea name="sEvent" id="sEvent" rows="8" cols="55"></textarea><br />

            <label for="File1">Attach a file:</label>

            <input type="file" name="File1" id="File1" /><br />

            <div id="buttons">

            <input type="submit" id="Button_OKEdit" name="OK" value="OK" />

            <input type="submit" id="Button_CancelEdit" name="OK" value="Cancel" />

            </div>

        </form>

    </body>

</html>

Take note of two places in particular that you’ll need to alter for your site—the option value (and text) for ixProject and ixArea.  These are set in this html example to the raygun project I referenced in the last post.  I had to strip out any references to other public projects or areas that may have existed, or those would still be visible and defeat the purpose of isolating public projects.  Of course, you may want to have two or more projects available in this page in which case you will have to add those extra projects and areas.

Since you have full access to the source code, you can take this html as a starting point to customize it for your own site by changing the project name and option value (see that by viewing the source of your existing new case submission page with the public projects available) to ones that make sense for you.  Once you’ve done what you like with the html, put it in the website folder of your FogBugz installation, and call it from your FogBugz install like this:  www.myfogbugz.com/raygun.html

Thanks especially to Stefan, one of the Fog Creek programmers, for helping me get the hacked apart html into presentable shape!

Edited on July 18, 2008 to add: If you will be using the public HTML form with FogBugz On Demand, you will have to go to Settings->Site->Advanced in your account, and uncheck "Protect actions against Cross-Site Request Forgery".  The forgery protection is to prevent other sites from submitting possibly malicious data into FogBugz, and unfortunately also blocks this sort of HTML form. 

Projects in FogBugz can be configured to allow public submissions through the web.  This is a very nice feature, but it has two potential drawbacks.  The first is that all public projects are visible to all visitors, and you may not want some people to know about the existence of a particular project for whatever reason.  The second is that anyone who comes to your site can submit cases.  This may be just fine, or even desirable, for most companies, but there may be a need to keep one project secret, and yet still grant access to a segment of your customers; or perhaps you simply want one project associated with a single url so you can send the people you want to the right url.

Luckily there is a simple way to get this done.  Let’s say you have 2 projects but you want a separate url for the public submission page for each project, so that there is only one project available on each page.  We’ll call your two projects “ray gun” and “spacesuit.”  To give ray gun its own page you should first make sure the project allows public submissions.  You do this by editing the ray gun project on the Projects page and choosing “Yes” for the “Allow public submissions” selection.  If you were to log out now and hit your FogBugz page you would see a line that says “Enter a new case.”  Selecting that would bring up the new case form with a list of all the publicly available projects. 

To get a page that just has the ray gun project as the project option in a new case, you will need to:

1)      View the page source (right click, view source in your browser) on the page after you have clicked the “new case” link. 

2)      Find the line that has the html tags for option and lists all of your public projects.

3)      Remove all the tags for the projects you do not want displayed and leave only those you do.

4)      Save that file with some name—I saved mine with the name raygun.html.

5)      Place that file in the FogBugz website directory,

You can then give out the url http://yourinstallation/raygun.html to send people directly to that page with ray gun as the only option.  You simply repeat the process for the spacesuit project and you can send users directly to the page you want.

Of course, if you then want to restrict who can go to that page you can control access with .htaccess or making changes to your web server’s security permissions.

In my next entry I’ll supply an example file that’s been stripped down that you might alter and use on your own site.

Although we already have a knowledge base article about this topic, it’s come up 3 times this week from customers, so it seems like a good candidate for some extra attention in the blog.

FogBugz gives each case a unique case number—unique for that installation that is.  FogBugz handles incoming email by either creating a case if one does not exist, or by appending the new email to an existing case.  It uses the number in the subject line to determine which case to add the new email to.  With this fact you can probably see the contours of a possible problem.

Given the growing number of FogBugz installations out there, case numbers can “clash.”  By that I mean that if I have an installation that sends an email with case 100 in the subject line, and the recipient installation also has a case 100 (more than likely having nothing to do with the original case 100), then the email gets appended to the wrong case, and confusion can ensue.

There is an easy solution for this, one we use here at Fog Creek, and that is to add a prefix to your case numbers in emails.

You’ll want to pick some set of letters that you think will be unique, or at least rare—we use “FC” here.  Then alter the sCasePrefix variable.  In a Windows installation make a registry entry at HKLM\Software\Fog Creek Software\FogBugz\[path to your install]\sCasePrefix

In a Unix installation make a value in the application.data file (fogbugz/Accessories folder) called sCasePrefix

Then you’re all set.  You’ll be merrily emailing between installations with no clashes between the cases.  The actual case numbers will not be altered in your installation, so case 100 remains case 100—the prefix is only added to emails sent out from your FogBugz installation.

News of FogBugz On Demand has been seeping out in various places--on our trial page, in some of the online documentation, and in Joel’s discussion forums.  We’ve been working on it for a while now and are well into the beta.  As part of that beta we’ve started making all new trials of FogBugz automatically part of On Demand.  At the end of the free 45-day trial, you’ll have the option to start paying for On Demand, or purchasing our traditionally licensed FogBugz installation.  Some users are nearing the end of the free trial period and as this point gets closer we’re hearing from more people wondering whether they can take an existing database from their own FogBugz installation (or even from a trial started before we moved to the On Demand code), and import it to their new On Demand account.  The answer is, of course, yes you can.  But, we have to do it for you.  Here is what we’re going to need, in addition to a current support contract:

1)      We need a copy of your database in Microsoft SQL format.  It’s easiest if we can get it in MDF format, but a BKP file will work as well.

2)      We need the name of your On Demand account, i.e. what your url is, abc.fogbugz.com

3)      Pack the database file and the information in a nice friendly message (we like those best) and send it to us.

Prospective customers often ask about who our clients are, that is, who's using FogBugz.  They probably want to feel confident about the future of Fog Creek and don’t really have questions about the quality of the software, which they usually determine for themselves anyway by signing up for a free 45 day trial. 

The answer to the question “who uses FogBugz?” is: a lot of different companies.  But that answer won’t do, and as a matter of policy—to respect the privacy of our clients—we don’t give this information out.  Other companies often have a hit parade of their clients listed on their website, but obviously we don’t.  But the question still needs answering.  Our default response is to tell people what industries our customers come from as the next best answer to telling them who the clients actually are.

I’ve been answering this question whenever it comes up, and it comes up regularly, so in the spirit of Joel’s article on customer service and Thomas Limoncelli's book,  I’ll attempt to fix it once (Joel actually says to fix it twice, but Joel and Limoncelli are making the same excellent point).

Many of our clients are well known, and they are housed all over the world.  Here is a sample of our clients' industries.

Software development

Investment banks

Law firms

Aerospace

Research universities

Private colleges

Law enforcement agencies

Media companies

Federal and State Government agencies

Medical companies

Tech support

City governments

Game developers

Accounting firms

Music publishers

Mobile phone companies

Cartage companies

And more…

FogBugz is used by small teams and huge organizations in all sorts of different industries.  I hope this list helps give a sense of who uses FogBugz, and demonstrates the range of our clients, and thereby addresses what people are interested in learning when they ask, "who uses FogBugz?"

More people are realizing that FogBugz is not merely a bug tracking tool, but can also be used as a project management tool.  A number of features have been added that move FogBugz in this direction, and more are on the way.  I suspect we’ll be talking at length about this topic over the coming months.  For now, though, I would like to point out a lesser known feature that can be quite nice, namely release notes.

If the users of FogBugz are conscientiously keeping notes on relevant cases in the development of a new version of software or other project, FogBugz will allow you to create a list of notes in either XML or HTML format that you can use as a summary of all new features.  This removes the burden off having to keep track of this in some other location not connected to the cases in FogBugz, or worse, trying to sift through hundreds of cases to determine which ones are relevant to your new release.

To make a note for a release, the case must be resolved, but not closed; otherwise you won’t see the release notes option.  Adding notes to the right kinds of cases in words you want the world to see is the key to making this useful.

You can read about this in more detail here.