Subcases and Hierarchy
September 2nd, 2009 by Ben Kamens
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.
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.