GTD, HPDA, and text files
September 16th, 2005 at 11:49 am by Dr. Drang
A few weeks ago I read this post by Merlin Mann over at 43 Folders. It has to do with keeping all your information in one big text file, using the search capabilities of your text editor to get at things quickly. It’s presented as a sort of über-geek thing to do, although I first read of it several years ago in columns by the decidedly non-geeky (except in how he looks) James Coates, the computer columnist of the Chicago Tribune. Coates has always struck me as shill for the software industry, with only the shallowest knowledge of things computer (he’s like the instructor who’s reading the text book two weeks ahead of the students, and when his readers ask for help in his weekly Ask Jim column, his standard response is to simply steer them to some commercial software) but he recognized the value and portability of keeping one’s information in a format that can be searched, read, and edited by any text-handling program on any platform.
I have, however, always thought that putting everything in the same file was too much. I kept my address book in one file; my calendar entries in another (this was before I succumbed to the Apple Way and dumped all my PIM info into Address Book and iCal); project names, numbers, and contacts in another; and so on. A comment on Merlin’s post struck a chord with me:
I try to get the best of both worlds. I keep notes in lots of separate text files. When I need to look at them as one big file, I use blosxom to string them together as html.
I wasn’t looking to concatenate all my text files, but did want to organize my GTD next actions and waiting for lists. (OK, I really wanted to create these lists. I’d always put off making them because I wanted to have a good system for keeping and organizing them.) Since I already use Blosxom for this blog, it seemed like a good fit.
It wasn’t—at least not for frequently-revised files like these GTD lists. Blosxom was great at presenting the lists, but no good at editing them. Fortunately, the experience led me to do some real thinking about how I work and what I need (and will actually use) in a GTD list-keeping system.
My needs for the system are:
It must consist of text files. The surprising (to me) reason for this has nothing to do with portability or universality. Unlike other information that I insist on keeping in text—or easily-converted-to-text—files, the GTD lists are both small and ephemeral, short bits of instruction continually overwritten. I could create them in a word processor or a spreadsheet or a database and not worry much about the time required to remake them when I decide to switch from, say, Excel to Pages. No, the reason they must be text files is that I am, and expect to always be, most often working in a text editor, and I want to take advantage of the habits and muscle memory that come from heavy use of a single program.
It must allow me to move easily from project to project within contexts and between contexts. By “contexts,” I mean David Allen’s @work, @home, @computer, etc. In my life, the boundaries between these contexts are not sharp, and I won’t use the system if I can’t shift quickly. Moving from project to project within the work context is even more important, as the priorities of my next actions are dictated by my telephone and the clients on the other end.
It must be easy to print the lists on index cards. I do not have my computer in front of me at all times, and when I am without it I use my HPDA. While there are some lovely templates for handwritten lists, I want the lists themselves to be printed, with handwritten entries only when ideas come to me away from the computer.
Here’s how I try to meet those needs.
First, you should know that the text editor I use is BBEdit, and the descriptions of how I achieve certain goals will be specific to BBEdit. That doesn’t mean that other editors won’t work, it just means that different steps would have to be taken to make them work.
In my home directory, I have a folder called “gtd.” In this folder, I have a text file for each context: currently “work.txt,” “home.txt,” “computer.txt,” and “car.txt.” I suppose the “.txt” extension is unnecessary, but it helps distinguish the GTD list files from another file in that folder.
Each text file has (potentially) several sections, set off by header lines. My “computer.txt” file currently looks like this:
Blog
----
Next actions:
* GTD HPDA printing and "one-big text file"
* Combining Markdown and ASCIIMathML
Waiting for:
Infrastructure
--------------
Next actions:
* Reconfigure servers so offsite backup is to
newer machine (eliminate older)
* Gather info on Bluetooth scrollmouse choices
Waiting for:
Dynamic picture frame
---------------------
Next actions:
* Gather info on screensavers
* Change JavaScript web page to use folder
of photos instead of hard-coded list
(may require CGI)
* Size and price display boxes at Hobby Lobby
* Remove LCD and decide on type/size of matte
Waiting for:
Media
-----
Next actions:
* Install `galleon` (see del.icio.us "tivo" bookmark)
on server for TiVo
* See if Picasa can show nested directories
Waiting for:
The header lines (with the dashed underlines) are the names of the various projects. Within each project there is a “next actions” section and a “waiting for” section. (It happens that my computer “waiting fors” are empty right now.) The items in these sections are set off by an initial asterisk. This formatting is a subset of Markdown, a formatting syntax that’s easy to read as plain text and allows for easy conversion to HTML (which will come in handy when we get to printing).
I open all the context files in a single BBEdit window and turn on the navigation bar (more on how I do this below). What I get is something like this:
The popup menu in the navigation bar allows me to move quickly from context to context.
To move from project to project within a context, I can of course scroll or use the Find command, but I prefer to use markers. Further, I want the markers to be made in one fell swoop. To do this, I open BBEdit’s preferences and add a search and replace pattern I call “Markdown header.” The search pattern, ^(.+)\r[=-]+, looks for a line of anything, which it captures, followed by a line of dashes or equals signs. The replace pattern is simply \1, which is what was captured in the search.
Now I can choose Find & Mark All from the “M” popup in the status bar,
and choose the Markdown header pattern from the Patterns popup of the sheet that comes down
This creates a set of markers in the file that can be accessed through the “M” popup to move from project to project. Not a big deal in a file with only a few projects, but my work file may have twenty or more projects.
These GTD files are the only files I regularly open in a single window and, therefore, the only files for which I need the navigation bar. To reduce the number of steps I need to take to open up the files, I wrote the following AppleScript and saved it in ~/Library/Application Support/BBEdit/Scripts/Open GTD.scpt.
tell application "Finder"
set shortList to name of every file in folder
"HD:Users:drdrang:gtd" whose name ends with ".txt"
end tell
set longList to {}
repeat with shortName in shortList
set longName to file ("HD:Users:drdrang:gtd:" & shortName)
as reference
set longList to longList & {longName}
end repeat
tell application "BBEdit"
open longList opening in new_window
set show navigation bar of window 1 to true
end tell
This script was kind of a pain to write—it seems like all AppleScripts are. I thought I could just get the list of files from the Finder and open them in BBEdit. But that always gave an error, so I had to add the goofy section in the middle that takes the file names, prepends the path, and turns them into a list of references. If someone knows a simpler way to do it, I’d like to learn it. In any event, the script shows up as “Open GTD” in the Scripts menu of BBEdit, and now I can open all my GTD lists with a single menu selection.
At this point I have basically satisfied the first two needs listed above. The last need, printing the lists onto index cards, involves a Unix filter, a couple of Perl libraries, another AppleScript, and a couple of other command-line programs. Although it works easily, it will take quite a bit of explaining, so I’ll give it it’s own post. When that post is done, I’ll come back here and add a link to it. Here it is.
