The to-do graph
Earlier this year, I started practicing GTD.
I’m not very good at it yet. But I’ve learned some things.
And I’ve proven that lists suck.
A list is a single, flat, ordered collection of items. In GTD, you’ll have one list per project, and each item is an action.
This makes sense if you consider the list to be a record of everything you did toward that project, in order, written before instead of after.
But who does that?
Who micromanages the order of things they’re going to do before they do it?
Who has such perfect foresight?
Who has that kind of time?
Moreover, the order of a list is implicitly transitive: Every item in the list must come after every item before it and before every item after it.
That isn’t true: Some things can be done at the same time, or in either order. For example, you can work on assets while you install Xcode, and then you can work on assets before code or code before assets.
A list is a serial queue. No work can proceed until the work before it is finished.
The alternative to that is to throw out the ordering altogether: Put items in in the order you think of/receive them, and then every time you want to start one, scan through the whole list until you find something that you haven’t done and can do.
It’s a choice between false information—order relationships that don’t really exist—and no information.
The latter seems worse: Some of the orders are true, and therefore valuable, so why throw them all out?
How can we avoid that?
What makes the true orders true? Why do those actions have to be done before those other actions?
Dependencies.
This action must be done before that other action because the other action depends on it.
Some actions depend on other actions. Some actions depend on multiple other actions.
This is a graph.
That’s what I’ve switched to. I still use OmniFocus (version 1), but only as an inbox; I migrate those items to my to-do graph, which I keep in OmniGraffle.
You can tell this is a made-up example because some of these actions are not concrete enough to be proper GTD.
The graph enables me to express dependencies without making up false orderings. Items that can be done in parallel are in parallel.
I mainly edit the outline, rather than the boxes on the graph directly. You could use something like OmniOutliner or TaskPaper, but those can’t visualize the graph. OmniGraffle has an “auto layout” (no relation to the Cocoa feature) option that automatically creates and arranges boxes in the graph corresponding to items in the outline.
The top-level items in the outline, the roots of the graph, are goals. I typically write these as high-level imperative sentences such as “build initial version of app”.
All, or occasionally nearly all, of the other nodes are indivisible actions. Each is a single concrete step toward the goal.
The leaf nodes are “next actions”: At any time, I should be able to pick a next action as the next thing I’m going to do.
I also create nodes for other people’s actions that I’m waiting on. These nodes look like “So-and-so: Do such-and-such”. When that happens, I take it off; its parent—if it has no other dependencies—then becomes a next action.
I set OmniGraffle to lay the graph out as an upward tree, so that each project actually does look tree-like, with the “root” at the bottom.
To mark an action as done, I have two choices: I can set the node’s font to strike-through, or just delete it. I typically strike through my own completed actions, and delete obviated actions, completed actions by others, and completed goals.
You’ve gathered by now that OmniGraffle lacks some things for this.
- It wasn’t designed to be used as a to-do list, so it lacks a concept of “done”. Instead of a checkbox, I have the Font Panel.
- Similarly, there are no priority or due-date options. I generally don’t use these, but some projects do, in fact, have a due date, or greater or lesser priority than other projects, and it’d be helpful to track that.
- The outline editor, which superficially looks like a mini OmniOutliner, lacks or changes about half of OmniOutliner’s keyboard commands. I really wish that if the keyboard focus is on the outline, that it would just respond exactly as OmniOutliner would to every possible keypress.
- The option to have a node pinned to the far (top) row of the tree is a per-node option, so I can’t have it automatically lay out all next actions in the same row.
- The outline structure, like OmniOutliner’s, means I cannot have multiple nodes depend on the same action—which they very well could in reality.
I have two points:
- A graph is a much better way to express to-dos than a flat list.
- There currently isn’t a Mac app ideally suited to this. OmniGraffle is a great graph editor, but I’m using it for a purpose it wasn’t designed for. I’d pay good money for an app of OmniGraffle’s quality and basic nature, but optimized for to-do keeping.