Friday, February 24, 2006

Switching From Trac to OmniOutliner Pro

When I first started developing Mac software, I used OmniOutliner to keep track of feature requests, bugs, and notes about what I was working on at the moment. It was great for organizing little bits of information, but it wasn’t quite powerful enough.

I soon switched to a Mac build of CVSTrac. Being Web-based, this was more cumbersome to use, but it provided better search options, and the Web interface made it very flexible at displaying different windows and views of the information. Most importantly, it integrated with CVS. CVSTrac includes a great CVS browser, which I could have used by itself. But I also used it to track issues, because I wanted to be able to see which tickets corresponded to which check-ins. CVS assigns revision numbers per-file, but CVSTrac is able to group the revisions (and display the changes) by check-in. It has a nice timeline that interleaves check-ins and ticket changes. CVSTrac isn’t good for storing rapidly changing notes (which I create and edit while coding a particular feature or fix), so I used BBEdit for that.

Naturally, when I switched from CVS to Subversion, I switched from CVSTrac to Trac. I like Trac even better than CVSTrac, except that it’s kind of a pain to install. When I got my iMac Core Duo I started thinking about building a universal binary version of Trac and realized that would be even more of a pain.

(I want to be able to sync it between my iMac and PowerBook and run it at full speed on both machines—Web applications are slow enough without Rosetta. Actually, to run in Rosetta isn’t quite trivial, either; it would probably involve making a stripped python binary and changing some shebang lines.)

None of this would have been difficult, but it was enough work that it got me to think about whether there might be an easier way. At this point, I realized that I don’t need Trac for issue-tracking. Subversion has built-in support for revision numbers, so I can use a separate tool for issue tracking and simply enter the revision numbers in the appropriate places. Since I’m a solo developer, I don’t need a Web-based solution; I can use a real Mac application that saves regular files to disk. When I need to browse Subversion, I can use BBEdit, or fall back on Trac.

The tool I chose for issue tracking is OmniOutliner 3.5 Pro. My use of versions 1.x and 2.x was very basic, and so I kind of ignored the later releases because I didn’t think I’d be using their extra features, anyway. Now I see that 3.5 Pro is a huge improvement, to the point where I can use it for all kinds of things that 2.x wouldn’t have been able to handle. I’ve always liked outliners, but I didn’t use them as much as I would have liked to because there weren’t any that did enough of what I needed. OmniOutliner 3.5 Pro seems to be the release that crosses that threshold.

The most important new features for me are sections (for navigation and scoped searches), styles (very useful, even just for on-screen editing), and attachments (to associate troublesome input files, code, and documentation with a row). I also appreciate that it’s much less buggy than 2.x was.

In addition to the stuff from Trac, I’ve moved some lists and notes that used to be in BBEdit into my Issues outline. Obviously, the biggest improvement is that it’s much easier to make small changes and to re-arrange items compared with using a Web-based interface. It’s like taking off a straightjacket. And I prefer a flexible hierarchy, combined with columns and styles, to Trac’s Component-Milestone-Priority-Severity filing system. But, more than that, OmniOutliner has achieved a level of polish such that it no longer gets in my way. This makes all the difference because OmniOutliner is now (along with BBEdit and Mailsmith) one of the applications that I think in. Anything that isn’t fluid is is more than an annoyance; it’s an impediment to thought.

However, I’ve also noticed two somewhat unexpected benefits compared with Trac. First, it makes much better use of screen space. I can see more in less space, especially when I use the Hoist feature. Second, it’s nice to have my outlines in a separate window layer from my BBEdit and Safari windows. True, Mac OS X windows aren’t rigidly layered by application the way they were in OS 9, but the tendency is still there. I like to be able to bring all my code windows to the front by clicking on BBEdit’s Dock icon, but I also like that this doesn’t bring my notes to the front, since they’re in OmniOutliner.

On the whole, the switch has been great, but there are a few areas I’m not satisfied with yet. First, I’d like to be able to open more than one window for each outline, so I could view different parts of it at once, or view details along with the main structure. This would be great in combination with hoisting. Second, OmniOutliner can be very slow when pasting in a lot of rows. Lastly, I haven’t quite figured out when to use child rows and when to use notes. With 2.x, this was obvious, but 3.5 Pro offers so many options—for formatting rows, temporarily collapsing row text, showing notes inline, and spanning them—that the distinction between rows and notes is blurry in my mind. For now, I use rows for everything.


Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment