Hide full article
In his recent TidBITS article, "Getting Things Done With Your Macintosh" (24-Jul-06), Jeff Porten explains the general Getting Things Done (GTD) philosophy, and mentions some software that might be used or adapted for maintaining GTD lists. My experience, though, is that it's not easy to adapt existing software for GTD.
This might seem surprising, considering what a hard-core outliner wonk I am. But an outliner, out of the box, makes a poor GTD aid. An outline's hierarchical dimensionality just doesn't match the way you maintain a GTD list. The addition of columns helps, and an application like OmniOutliner Pro or Tinderbox could certainly hold the data. But what's still missing is the interface to help you enter, maintain, and view your data, along with the logic that automatically adjusts things in response to your changes.
(Ethan Schoonover's Kinkless GTD tries hard, using AppleScript, to bend OmniOutliner Pro and iCal into a GTD list, but I've found it disappointing. Similarly, Ryan Holcomb's GTD Tinderbox template is an ingenious nightmare of workflow rules that it's up to you to remember.)
New Rock on the Block -- Recently, though, I've discovered a new application explicitly dedicated to GTD. It's Thinking Rock, a well thought-out freeware application from a couple of developers in Sydney, Australia. The latest version, 1.2.2, has been particularly worth waiting for.
Behind the scenes, Thinking Rock maintains an XML file - a choice that I very much appreciate, since in an emergency any text processor can access your data. This file effectively describes a lightweight relational database, so it has the dimensionality necessary to implement a GTD list.
On the surface, meanwhile, Thinking Rock's interface behaves as a kind of wizard, a series of screens that guides you through the process of constantly forming, maintaining, and reviewing your GTD list. This is a great approach, because it not only handles the logic of the GTD process for you, it also embodies (and teaches you) that process. The developers have clearly taken to heart the GTD philosophy, in detail, and have been at pains to express this through Thinking Rock's screens. I'll describe the screens for you, so you can see what I mean.
Off to See the Wizards -- The first two screens have to do with how things get into your GTD list. Think of them as the door to your list; everything passes through here.
In the first screen (Collect Thoughts), you enter things you want to do ("thoughts") as they occur to you. The idea, though, is that this screen should never have contents for very long - no point hanging around the doorway! In the second screen (Process Thoughts), you categorize each thought, one at a time, and when you do, it automatically disappears from the list of thoughts in the first screen. That's because a processed thought is no longer a thought. It is now something else (an action or a project, or else a future item or an information item - I'll explain those terms in a moment); it has passed through the door, and is now in the list.
Here's how you categorize a thought in the Process Thoughts screen (and observe that your options are remarkably faithful to the GTD Workflow paradigm):
- If you decide that a thought is actionable (it is a "thing to do," as it were), you describe the thought's outcome, so that you know what "completion" would mean; you give the thought a description; and you decide whether it can performed in a single step. If so, the thought becomes an "action;" if not, the thought becomes a "project." (So, an action is a doable thing; a project is a sequence of actions, and can contain sub-projects.) In the latter case, you'll eventually need to give the project some actions - cleverly, Thinking Rock creates an initial action reminding you to do this! Finally, you choose how to dispose of your action: postpone it ("Inactive"), mark it to be done as soon as possible ("ASAP"), assign it a due date, or delegate it to someone else. If you delegate, you can create an email message to ask the person to do it, and you can provide a date on which you should follow up to check whether it's been done.
- If you decide that a thought is not actionable, you can either delete it or postpone it into one of two categories, a "future item" or an "information item." Future items and information items can be revisited at any time in screens of their own; they appear as simple lists, and if at some point you decide that such an item is now actionable, you can move it back to the "process thoughts" wizard and reprocess it. This approach - which is one of unabashed procrastination - is in line with the GTD philosophy, where (as "bsag" has well expressed it) "[you] capture everything you have on your mind in a safe place, and thus stop subconsciously worrying about it [even if it] might not come into play until some time later."
Now I need to mention two supplementary screens that are used to provide your actions and projects with additional categorical depth. "Topics" are general areas of thought and life, such as Work and House. "Contexts" are physical environments or modes of working in which you might actually perform an action, such as Phone, Computer, or While In Town. In their own screens, topics and contexts are simply lists. In the rest of the interface, topics and contexts appear as pop-up menus. Thus, you can change the topic and/or the context of a thought, action, or project in various screens, but (in true relational database fashion) in order to change what topics and contexts exist, you must use these supplementary screens.
All that remains is to view and maintain your actions and projects. There are five screens for doing this. First, there's a compendious screen (Review Projects). On its left is an outline containing all your projects and their actions, and all your single actions. Here you can rearrange actions; you can also promote an action into a project. On the right is an inspector where you can modify features of whatever project or action is selected on the left. So, for an action, you could use the inspector to change its description, its topic, its context, or its disposal (including marking it Done). For a project, the inspector displays four text fields for various sorts of planning notes.
The remaining four screens are nearly identical. At the top, each displays a subset of your actions as a sortable list; at the bottom, they show the same outline and inspector as the compendious screen I just described, and whatever action is selected in the list at the top is revealed and selected and inspected at the bottom. The difference between these three screens lies in what subset of your actions is listed at the top: your ASAP actions, your Delegated actions, your Scheduled actions, or all your actions with the capability to filter by type, context, and due date.
So day by day, from time to time, you look over your actions and, one hopes, you do stuff. Sooner or later, one hopes, you'll mark an action or a project as Done. At that point, it is filtered out of the display (but it isn't deleted from the data file, so if you want to see Done actions, you can). The cleverness of the implementation is that filtering prevents inappropriate things from hanging over your head; for example, looking at your ASAP actions, you don't see your Scheduled or Delegated actions, so you're not prematurely overwhelmed.
Inactive actions are usually filtered out too, which helps to handle the common real-world situation where starting Action B must wait upon completion of Action A. You make A and B successive actions of a project, with B as Inactive so it's hidden. Now check the Sequence Actions checkbox for that project. (Turn this feature on in Preferences > Screens > Projects.) When A is marked Done, B springs automatically to life, becoming an ASAP action. Thus, B stays off your plate until A is done. It's a primitive mechanism, and no substitute for a true dependency implementation, but it's better than having to maintain such sequences manually.
Putting It Out There -- Thinking Rock provides various ways of exporting information. First, there are reports. These are PDF files, where actions have checkboxes, so printing is your likeliest next step. Using reports, you can list actions due ASAP or this week; actions ordered by date; actions grouped by context (though in fact the previous two types of report also group actions by context); and actions grouped by project. You can also create a PDF consisting of eight pages in one, suitable for cutting and folding into a PocketMod booklet.
Actions, future items, and information items can also be exported as simple text or in XML format, thus giving you the power to process this information further in some automated fashion (perhaps parsing it and importing it into some other program).
Finally, a preference lets you turn on automated iCal export: if you do, an .ics file is created whenever the underlying XML file is saved. This is quite a brilliant little device, not least because iCal, unlike Thinking Rock, has a reminder feature. On the other hand, getting iCal to see the exported calendar can be a little tricky. One approach is to choose File > Import within iCal, to import the calendar manually; but this puts the onus on you to re-import every time your Thinking Rock information changes, and also you must manually delete the calendar from iCal before re-importing it, or you'll get duplicates of everything. A neat alternative is to turn on Web Sharing, maintain the .ics export in your Sites folder, and tell iCal to Subscribe to the corresponding URL. A subscribed calendar can be refreshed automatically or manually (or both), so you can now easily stay up to date.
Conclusions -- There are, to be sure, aspects of Thinking Rock with which one might quibble. The biggest flaw is that this a Java application, consisting of a single great big (and rather ugly) window; it doesn't feel the least bit Mac-like. The recent update has alleviated a few of the grossest annoyances: you can now use a menu item rather than editing a configuration file to specify where your XML file is, and the window now remembers its size between startups.
Nevertheless, just about every interface detail is infuriating. There are no provisions whatever for styled text. Keyboard navigation works all wrong when filling out Collect Thoughts fields, and text editing tools are primitive. If Thinking Rock is in the background and you click on its window to switch to it, and your click happens to be anywhere to the right of the "Inactive" radio button in the Process Thoughts screen - even way on the other end of the window - that radio button is selected. It doesn't remember the expansion state of projects and their actions or sub-projects, and there's no Undo capability at all.
There's no way to relate an action to a file on disk. There's no integration with Address Book; in fact, when you delegate a task to someone, Thinking Rock doesn't even remember this and offer that same person as an option later. In the automatically generated sentence in the Note field of an action describing its successful outcome, the word "successful" is misspelled, for heaven's sake!
For all of these reasons, I must admit that every time I use Thinking Rock, I cringe slightly; my first impulse is to fix its interface stupidities myself, by cloning it as a Cocoa application. (If I don't soon do this, I wouldn't be surprised if someone else does.) Nonetheless, Thinking Rock's is the first interface I've seen in any Mac-native, stand-alone application that is directly expressive of the basic Getting Things Done paradigm. It's simple, straightforward, and clear. Good online help is included. The program is eminently usable, as it stands, clunks and all; and one can't quarrel with the price. Plus, the developers solicit (and listen to) suggestions.
So, if you're intrigued by the Getting Things Done concept and want to start implementing it in your life, I recommend that you take a look at Thinking Rock. No need to buy the book, read the blogs, or drink the Kool-Aid; Thinking Rock will have you getting things done in no time.
Thinking Rock is a free 12 MB download. Because it's a Java application, it is available for Mac OS X, Linux, or Windows. For Mac OS X, the main system requirement is that you must be using Java Runtime Environment (JRE) 1.5; if you are not, you can obtain it through Software Update. (I do not know if this means that Thinking Rock won't run on Panther or before.)
Staff Roundtable -- All this is one man's view of Thinking Rock and its role in the Getting Things Done model. But there are other adherents to the system on staff.
[Tonya Engst]: One thing that wasn't entirely clear to me when Adam demoed Thinking Rock was how to deal with recurring actions. Let's say you have a project to pay quarterly estimated taxes that requires a number of different actions: transferring money to the right bank account, calculating the numbers, filling out the form, etc. As we looked at the Thinking Rock interface, it turned out that the way you would handle this is to create your project, assign a date to the first action in the project, and make all the others Inactive. After completing that first action on the defined date, you wouldn't mark it as Done, but would instead reschedule it for the next quarter, marking all of the project's subsequent actions as ASAP. And once they were complete, you would mark them not as Done, but as Inactive again.
[Adam Engst]: For me, the Getting Things Done model falls down in two ways, only one of which Thinking Rock helps with, at least in the short term. First, as I come up with a system and use it regularly, I become bored with it and start to let the necessary ongoing maintenance of it slide until the system stops working and I try something new. My theory is that GTD's popularity is due in part to a feedback loop caused by people talking about it, developing tools and techniques, and sharing implementation ideas. All that keeps the model fresh and interesting, and we, or at least I, am drawn to things that are fresh and interesting. So at the moment, Thinking Rock is fresh and interesting, and I'm back on the wagon with GTD. Will that last? No telling, but perhaps if Thinking Rock itself evolves, that will be sufficient to keep me interested.
Second, the GTD model deals poorly with types of work that require hours upon hours of concentrated effort on a single action. If I'm writing a book or a long article, I need to sit down and write for long periods over multiple days or even weeks ("Write Chapter 1" is not necessarily quick). The overall project may have multiple actions, but if a single action takes a long time, it's entirely unsatisfying to have it in GTD, since it hangs out being uncompleted the entire time. I've never found a way in GTD to accomplish this, but since using Thinking Rock, I've been toying with the idea of having a type of action that has a user-controlled fill bar that would appear prominently for ongoing actions. After each session of work, I could update the fill bar to show to myself that I'm progressing and to make sure that the action remains on my list. In the meantime, I'll try a variant of the technique we came up with for Tonya's recurring actions. I'll make lengthy single actions into scheduled actions, and when I'm done for the day, instead of marking the action as completed (since it isn't), I'll reschedule it for the next day I plan to work on it.
