PanaGeek

I have tried a countless number of GTD apps over the past couple of years – web based, browser based, Microsoft Office based, text based, and so on. My current favorites are my TextMate GTD bundle at home, and Thinking Rock at work.

I think that my requirements for a GTD app come down to three criteria, in this order:

Ease of data entry. This is what kills most applications for me, and probably what makes text file based GTD apps work the best. I hate the “type, click, click, type, click” data entry model that most GUI based apps use. Plain text with tab completions seems to be the most natural way to go. Thinking Rock is GUI based (in Java, no less) but I can enter a bunch of tasks with no clicking – that comes later in the TR process.

Ease of task management. This is where text based apps can lose out to slick GUIs. TR makes it very easy to rack and stack tasks. The TextMate bundle may not be as flexible, but it does what I need it to do.

Portability. I used to think that this was extremely important – at one time I carried a full version of emacs on a thumb drive so that I could access my GTD files anywhere. Now, I’m somewhat happy with printing out my To Do list every morning and annotating on paper during the day.

What other metrics should be used in evaluating GTD software?

I am still working on a script that will allow a user to send a task to TextMate from QuickSilver. Adam Potthast sent a good example, but I’d like to add some functionality to the script. Specifically, I want the script to figure out what project and what context to assign to the task. So far, I have a long way to go.

I have tweaked the active list view to not show “wait” tasks. I think this helps me focus on what I need to do now. As always, feedback is highly encouraged.

Last week, I read Patrick Rhone’s article on GTD implementation that inspired me in a couple of directions. First, it was an awesome description of how to implement GTD from soup to nuts. Everything from how to build a to-do list to how to capture non-task data (an area that I have neglected, but am working on another posting to discuss). It was a great overview that took all of David Allen’s concepts and provided concrete examples. But, the other inspiration (the topic of this post) is his “Metadata Markdown” syntax for lists.

In a nutshell, this syntax works to provide “state” (my word, not Patrick’s) to a task. I have reversed two of the items, but here they are:

• (Dash): Undone Action Item.
• (Plus): Done Action Item. -> (Right Arrow): Delegated (with a note to whom and the date). <- (Left Arrow): Waiting – (i.e. for another action). ^ (Triangle): Data Point.

The difference between this and what Patrick devised is I reversed “Delegated” and “Waiting.” To me, the right arrow gives me the impression that I have passed the task along, where the left arrow better fits my thinking for a task that I am waiting on. I also added one more item:

• (Asterisk): Project.

So that I don’t have to keep writing “Patrick Rhone’s ‘Metadata Markdown’ Syntax”, I’m going to call it “OrgFu”

So, why am I writing about this? I developed a GTD bundle for TextMate over the past few months that was fairly close to Patrick’s model, and I thought his syntax would improve my bundle.

Now, how to setup this bundle.

Please read through this post. It describes the basics of how to get the bundle and set it up (Note – it is currently in the TextMate Subversion repository as “GTD2″ but this will probably change in a week or so). I still need to update that post to reflect these new features, but it works for now. Please also note that previous GTD bundle users will need to use this new contexts.gtd file with GTD2.

Now, to begin using this bundle.

Items are entered using a shortcut key and then pressing “enter” – just like before. The big difference is that the item now appears with an OrgFu prefix. Usually that is the undone action item state (-). While the contexts file has lines for DELEGATED (->), WAIT (<-) and DONE (+), they are there for generating views – you shouldn’t add a task in any of these contexts. Here are a couple of screenshots of the bundle in “action.”

Figure 1. A basic GTD project file.

Figure 2. Another sample file.

And now, where OrgFu shines.

In the old days (last week), changing the status of a task changed its context, like from TASK to DONE. That’s OK, but if you want to keep a long term file of past actions, this may become confusing – “did I call him, or did I E-mail him?” Now, thanks to OrgFu, the context never changes; only the state changes.

The various to-do list views from GTD are here in OrgFu, but I think they look even better with the OrgFu syntax. Also, they work better for printing and using during the day.

Figure 3. An Active Task View

Figure 4. What the GeekTool output looks like.

But what if you’ve been using GTD already?

You may be hoping that there is some cool AppleScript to convert from GTD to OrgFu. That means that you don’t know me very well. You’ll need to manually add OrgFu syntax to your existing GTD files. It took me about 5 minutes to add the syntax, and a few more minutes to determine that the views and GeekTool export were working properly.

So, what’s next?

Well, I just finished the initial build of this bundle. It will probably take a week or so to work out the bugs. The goal is for OrgFu to replace my original GTD bundle. As always, please write me to let me know what you think about this buundle and where you’d like to see it go. You can contact me at mike at panalaska dot org.