Tinderbox, OmniOutliner, and GTD (again)

A few months ago I bit the bullet and purchased Tinderbox, an interesting outlining/mapping/linking application for Mac OS. I primarily purchased it to use Ryan Holcomb’s template for a Tinderbox based system for the Getting Things Done workflow, but I also dreamt of using it for more.

I haven’t used Tinderbox much in the past couple of months. Kinkless GTD 0.83 came out along with the OmniOutliner 3.6 beta (now in final release), and it solved many of the issues I had with earlier versions of the KGTD/OmniOutliner combination. Prior to OmniOutliner 3.6, there was just a single toolbar customization setting for OmniOutliner. In most Mac OS X Cocoa apps, you can customize the toolbar pretty easily. It’s just one toolbar – not the big mess of toolbars that the Office systems have become. Generally, it’s been a very handy feature.

As OmniOutliner grew terrific Applescript support, they allowed you to add your scripts to the toolbar. Kinkless GTD is, in fact, a handful of Applescripts that do an implementation of the Getting Things Done method of planning / management. By putting a few new buttons on the toolbar, you essentially got a new specialized application that took advantage of the terrific nature of OmniOutliner (still the easiest and most fluid outliner on Mac OS X, and looks great too). The downside was that if you wanted to work on other outlines, the GTD buttons would still be there even if they had nothing to do with the document you were working on.

With OmniOutliner 3.6, you can now have document specific custom toolbars, meaning that my KGTD outline no longer interferes with other outliner documents. A few other concerns were dealt with in the new KGTD release that made it feel much more natural, and I found myself switching back to the OmniOutliner/Kinkless combination as my “trusted system”.

There’s a big difference in styles between how OmniOutliner / KGTD work and how Tinderbox / GTDRules work.

About OmniOutliner + Kinkless GTD:

• KGTD is an aggressive user of OmniOutliner’s extensive Applescript support (and in turn, OmniOutliner’s Applescript support has gotten even stronger).


• KGTD’s main unit of work is a big synchronization script that moves and copies outline elements around. In the Getting Things Done method, you “plan in projects and work in contexts”, and often need at least two views of your actions – the plan list, and the actual “do this next in this place” list. Kinkless GTD manages both by copying/merging/moving.


• By using AppleScript so extensively, Kinkless GTD works well with tools like Quicksilver, whose motto is “act without doing”. It’s easy to send an action into your KGTD inbox without ever switching applications or even taking your hands off the keyboard. Kinkless GTD has also done a lot of work to integrate with Apple’s iCal calendar, which in turn allows one to use various menu bar tools and Dashboard widgets to keep an eye on actions without having to bring OmniOutliner into focus. The use of applescript brings integration with other common tools.


• However, KGTD requires manual execution of the synchronization command. It’s possible to end up with ghosts and duplicates since it’s doing so much copying and moving. It’s gotten a lot better when it comes to the ghosts and duplicates, but it means that an active action may have two or three copies in the same document, all separate outline rows.


• OmniOutliner is a single-window application (well, single window per document). But with the new sections and navigation features in OmniOutliner 3, it’s quite easy to move around and focus on particular elements.


• As a native and modern Mac OS X application, built by a shop with a long history of Cocoa/OpenStep/NeXTStep development, OmniOutliner also gets to take advantage of many advanced Mac OS X features. Services, text system plug-ins, etc. This includes automatic spell checking, in-place dictionary look-ups, and more (ie – with “Equation Service”http://www.versiontracker.com/dyn/moreinfo/macosx/14090 installed you can easily convert LaTeX source to a rendered PDF and back again, without OmniOutliner ever knowing anything about LaTeX)

About Tinderbox + GTDRules:

• GTDRules is an aggressive user of Tinderbox’s system of agents and prototypes.


• GTDRules main unit of work is a collection of agents that are always running. Agents in Tinderbox are live queries which can also act on the items that they match. In the document view(s), found items are displayed as children of the agent. Most of the agents in GTDRules are ‘contexts’ (again – plan in projects, work in contexts), showing the next actions for the office, for home, for errands, etc, under the agent.


• Synchronization is always happening, so when an item is marked as complete, it disappears from the agent displaying it immediately.


• Data is not duplicated – the agent results are treated as Aliases, which you can also make manually in Tinderbox. Aliases are like their desktop / file system counterparts: a symbolic link. This way, there are no ghosts or duplicates.


• Tinderbox has a menu, customizable per document, called “Value”. You can use the Value menu to quick-stamp values on Tinderbox nodes. Since there are no checkboxes in the outline views, this is how you mark something as complete. But it’s also a way you can select many actions and set them all to be “Office” actions, in one swoop. Or put them on hold in one swoop. Customizing this menu is pretty easy.


• GTDRules also takes advantage of Tinderbox’s “OnAdd” rule setting, allowing you to set default values for nodes added – ie, a work project can easily be set to have its children be ‘Office’ prototypes so that they show up in the Office context, but projects for an on-site customer could default to ‘Remote’ instead.


• Tinderbox allows many windows to be open for a single document, and remembers their placement and displayed content. This allows one to take a big system like this and section it off into numerous views.


• Tinderbox, however, is very much a classic style ‘Carbon’ application. It still feels like a custom classic Mac application, and does not take advantage of many modern Mac OS X features – even ones that are available to Carbon, such as Services. This isn’t a HUGE deal – at least it’s native – but it’s frustrating to use the Font menu when I have so many many fonts installed that are so easy to work with in Cocoa text areas (using the font browser in OS X).


• Tinderbox has practically no Applescript support. It’s an island. Within the system there are a lot of things you can do. But you can’t easily send yourself notes from Quicksilver, from Mail rules, etc. There’s no integration with iCal or anything else. Using Tinderbox is almost like using Squeak on Mac OS X. Yeah, your mouse and keyboard and the clipboard all work, but beyond that it’s a universe unto itself.

Tinderbox’s isolation was a key figure in driving me back to Kinkless GTD / OmniOutliner. The GTDRules implementation on Tinderbox is a more “pure” implementation of the GTD workflow and easier to customize to one’s preferences (no applescript programming required). But data entry – especially of the quick “i need to remember to look at this later” variety – is not its strong suit here. There was something about it that started causing me stress when I’d look at my system. Maybe it was me getting sloppy and not cleaning / planning as well as I should. But something would just feel off.

All of that said, Tinderbox has a lot of great features that I’ve been meaning to explore. The euc.cx universe is ever growing, a great jumble of myth and fact, legend and memory. I’ve been wanting to start setting down all of the characters, locations, productions, etc, of it all and exploring the relationships. This is Tinderbox’s strong suit – links, relationships, visual maps (as well as outlines), prototypes, custom data, all should play in here. I really do need to keep myself still long enough to start learning how to do this. And I want to write again. Like really write, in hypertext, with relationships and cross references. I tried this once with ddec, a system based on an old implementation of the FTrain sitekit. But I hated writing in XML. (I just hate XML. I don’t care about it as a storage format, but I do hate writing in it, configuring in it, etc). This kind of writing is the real concept behind Eastgate as an entity. Whether anything will actually happen is hard to say at this point. But it looks like my writing desk will be in an excellent location in my new space and I hope it’ll help inspire me.

The view from where the desk will most likely be. (It’s a console table actually, just the right size for an iBook, a small lamp, a pile of notebooks, and the dog’s leash):