After a recent meeting with some members of our neighborhood association, of which I presently have the misfortune to be treasurer, I departed with my head spinning. Several complicated action items for me had arisen; how was I to keep them all straight? Worse, in two weeks I was leaving for Portland (to speak at a documentation writers’ convention) and Seattle (to visit an old friend), and each wing of this trip involved many preparatory tasks. How could I get all of those, plus the neighborhood association stuff, done in time?
No problem. The instant I got home, I did a massive brain dump into The Omni Group’s OmniFocus. Immediately, my mind was relieved; the stress was gone. What’s more, in those two weeks before my departure for Portland, I accomplished all the necessary tasks and then some – productively, without strain, without overwork, and without worry.
The purpose of OmniFocus is to implement the philosophy and techniques of Getting Things Done (GTD). My experience testifies that it accomplishes that purpose. Indeed, OmniFocus is the best GTD implementation I’ve ever used. Nonetheless, I do not yet recommend it for general use, because, in my opinion, problems with the interface would actually prevent most users from freely accessing and manipulating their data.
A Little Background — Doubtless you know by now what GTD is; if not, you might want to skim Jeff Porten’s discussion of Mac GTD applications (“Getting Things Done With Your Macintosh“, 2006-07-24), and my own review of Thinking Rock (“Get a Piece of the Thinking Rock“, 2006-10-09).
In that review, I mentioned Ethan Schoonover’s Kinkless GTD. It was an attempt, using AppleScript, to “misuse” OmniOutliner Pro as a GTD application. The idea foundered against some major limitations in OmniOutliner’s interface and functionality – and not for any want of trying on both sides, since as Ethan was hammering against the doors of OmniOutliner’s limits, Omni, in evident enthusiasm over his efforts, kept widening those doors, tweaking OmniOutliner to accommodate him. After years of futility, Omni finally did what they should have done all along: they opted to develop a full-fledged GTD application themselves. OmniFocus is the
result. (And, incidentally, they hired Ethan Schoonover as well.)
The GTD Structure — The GTD mentality relies upon a multi-dimensional classification of each task. There are two primary dimensions. On the one hand, a single atomic task – called, in OmniFocus, an action – is usually part of a project: it is a step along the way to accomplishment of a larger goal. And, an action typically has a context, the physical reality required for the action to be accomplished.
For example, to “prepare for the Portland trip” (a project) I had to “stop the mail temporarily” (an action) and “pack my bags” (another action). Actually, packing my bags was so large and opaque that I broke it down further into a list of things I wanted to remember to pack; an action with sub-actions in OmniFocus is called a group. Stopping the mail could be accomplished only “in the village” (a context; that’s where the post office is); packing an item could be accomplished only “at home” (another context). The idea is that a context can be consulted, when appropriate, for the next pending actions; for example, when I’m going into the village, I can take that opportunity to accomplish pending “in the village” actions from
To express this, the OmniFocus window toggles between two major complementary modes. In Project mode (as I call it; OmniFocus, wrongly in my view, terms it “Planning mode”), projects and their groups and their actions are displayed in a hierarchy, with each action’s context shown secondarily in a column; a sidebar (similar to iTunes) clumps projects into “folders” for easier classification and access. In Context mode, contexts and their actions are displayed in a hierarchy, with each action’s project shown secondarily in a column; the sidebar organizes contexts hierarchically among themselves.
There are actually three kinds of projects or groups. A sequential project or group’s actions must be performed in order; a parallel project or group’s actions can be performed in any order. Or, a project can be a list of single actions, meaning that it isn’t really a project at all; it’s just a convenient clumping of unrelated tasks. These differences are germane to the question of what needs doing: in a sequential project or group, the first uncompleted action “blocks” the others (they can’t be performed at all).
Time and Tide — OmniFocus also has an inspector window, consisting of four panes: action, group, project, and context. The inspector window exists partly to help you access minor settings that aren’t readily visible in the main window interface (such as, “When a new action is created in this project, what context, if any, should be automatically assigned to it?”), and partly to help express the dimension of time: an action, group, or project can have an estimated duration, a start date, a due date, and a completed date, or might be periodic or repeating.
There are also outline columns for estimated duration, start date, and due date; unfortunately, there is no outline column for the completion date, which means that you can’t easily learn what actions you completed on a certain date. Even worse, there is no indication in the outline that a repeating action is repeating; as a result, when you check off a repeating action as completed, it simply reappears unchecked, ready for the next repetition, and unless you consult the inspector, you don’t understand why.
In my opinion, the inspector window’s role is problematic here. The main window should express, somehow, everything important about every action; the inspector might function as a convenient secondary interface, but consultation of the inspector should never be required in order to know or do something. Additional columns, and perhaps some use of badging for repeated actions, should suffice.
Another problem is that the temporal dimension really demands a calendar component, including calendrical views and some sort of reminder alert system. (OmniFocus can sync with iCal, but actions become iCal to-do items, not events, so they don’t appear on iCal’s calendar; syncing is thus fairly pointless. For prior art, Omni might consult In Control, the long-abandoned but still unequalled master model of a columned outliner with searching, filtering, and superb calendar integration.)
Getting Stuff In — Like Thinking Rock, OmniFocus has a brainstorming mode where you just enter actions as they occur to you. Such actions go into a special region called the Inbox. You can enter actions directly in rapid-fire style (type an action, hit Return, type another action, hit Return), or indirectly from elsewhere: either you use a “quick entry window” summoned by a global keyboard shortcut in any application, or you can copy selected text from any application to the Inbox through a Service.
The idea is that from time to time you will study the Inbox and dispose of its contents. One approach is to assign each Inbox action a project and a context; you then choose Clean Up, which whisks the actions out of the Inbox and into their assigned projects. Alternatively, you can drag an Inbox action into its “real” location among a project’s actions (easiest if you open a second window).
Alas, some actions (“Try to take over the world”) are worthy but not currently feasible. I’d like a place to put such actions, so they are off my mind but still, somehow, on my plate. Thinking Rock lets me move such actions into simple lists of “future items” and “information items”; OmniFocus doesn’t. I tried creating an “Unfeasible” project; but its actions showed up inappropriately among do-able actions. My workaround is to mark the “Unfeasible” project as being “On Hold”.
A more serious problem is the Inbox’s peculiar status. To me, actions in the Inbox are actions; but OmniFocus doesn’t agree. For example, I might assign an Inbox action a context, but then leave it untouched, uncertain what more to do with it. In Context mode, such an action is not displayed at all. That seems wrong, somehow.
Getting Stuff Out — The reason for using a Getting Things Done application is to get things done. For that, you need first to know the status of everything: what actions there are, what’s left on your plate. In short, you need to find out what to do. Then, when you’ve done something, you need a way to specify that it’s done.
To help you discover what to do, OmniFocus lets you group and filter your actions in various ways. (Indeed, you are filtering your actions most of the time, since you rarely want to view completed actions and projects.) Some of these ways of grouping and filtering are a little peculiar. For example, when you filter your outline to see just the “Next Action” within each project or group:
- For a list of single actions, you see all its actions. (Fine.)
- For a sequential project or group, you see just the first action. (Fine.)
- For a parallel project, you see just the first action. (Why, if the actions are parallel?) But for a parallel group, you see all its actions. (Fine, but why this difference from a project?)
I find the behavior for parallel projects counterintuitive. It turns out, however, that to get the behavior I expect, I can filter differently, asking to see just “Available” actions. It took me much deliberate experimentation to discover this, and I worry that most users will be misled or confused.
I worry still more that users won’t even realize they are viewing a filtered version of the outline. Nothing about the interface warns you that you aren’t seeing all your actions; this can give you a false impression, and can result in seemingly inexplicable behavior. I’d like to see the window’s title change, perhaps, or a watermark behind the outline; or OmniFocus could copy Opal, which writes “Filtered” at the bottom of a filtered outline window.
Each action and group has a checkbox, and a project can have an Active or Complete status. The intent is that you check off each action as you complete it. So, then, wouldn’t you expect that when you’ve checked off all actions in a group, the group would automatically be checked, and that when you’ve checked off all groups and actions in a project, the project would automatically be marked Complete? Well, neither of those things happens. Evidently you are expected to discover manually that all actions of this group or project are checked, and deal with the situation manually (check the group, or mark the project Complete, yourself). But in that case, what’s the point of having a computer? A pencil and a notebook would be a more helpful
interface. There is no way to find groups or projects all of whose actions are completed, so how on earth are you supposed to know?
And another thing. It often happens to me that I switch from Project mode to Context mode and find my actions are gone! After a moment of heart-stopping panic, I realize that for some inexplicable reason, Context mode has appeared with all the context headers collapsed – the triangle next to each context points right, not down. Just click each triangle, or choose View > Expand all, and the actions are back. The same sort of thing often happens when I use “grouping”; for example, to discover what actions have pending due dates, you can group projects by “Due”. But the “Due within the next week” heading is collapsed, so you think that no projects are due within the next week – wrongly. Indeed, this entire issue with
collapsed headers makes me wonder whether the hierarchy, in a mission-critical task list such as OmniFocus, should be collapsible in the first place. Perhaps a full-fledged outliner is not an appropriate vehicle for GTD after all.
What we’ve seen is that instead of warning you that your view of the outline is filtered, OmniFocus makes you figure it out; instead of helping you find completed groups or marking them completed, OmniFocus makes you do it all manually; instead of revealing the actions you’re seeking, OmniFocus hides them by collapsing headers. In short, when it comes to extracting information, finding your actions and learning what needs doing, OmniFocus makes things harder than they should be. In effect, OmniFocus misleads you; and when you’re under the strain of trying to get things done, that’s bad. You constantly have to be alert so as not to be misled by the interface. It’s not so serious if you’re experienced and persistent, and
if you’ve relatively few actions and projects; but for most users, I think, using OmniFocus effectively would be quite challenging, especially as the database of actions becomes large.
Interface Woes — Much of OmniFocus’s interface is non-standard. Instead of using standard Cocoa widgets within the window, the Omni folks, for no reason that I can see, have invented their own – and they don’t work very well. The result, for me, is that the interface is largely unpredictable, intransigent, or annoying. Rather than extend this article with a catalog of detail, however, I’ve moved the discussion over to a couple of screencasts (which, by demonstration, make the problems easier to understand) on a separate Web page. If you want to hear me rant and sputter over OmniFocus’s interface, that’s the place to go.
The online help is poorly presented, with inadequate navigation, and without breadcrumbs to show you where you are; the style is unnecessarily snarky (“click the kinda arrowy-looking button”).
Conclusions — With all these gripes, you might think my assessment of OmniFocus would be largely negative. It isn’t. I would still insist that OmniFocus is the best expression of GTD on the Mac that I’ve ever used. Its existence has relieved me of stress and helped me accomplish more in less time. Gradually, I’ve become relatively proficient with it, and have grown fairly accustomed to its quirks.
If OmniFocus were a public beta, I’d be unhesitating: “Go for it!” I’d cry. “Join the beta party, submit plenty of feedback, and help improve this interface!” But OmniFocus isn’t a beta, and its price seems out of proportion to the state of its development. I’ve raved in the past about Omni’s interfaces; OmniGraffle is brilliant for drawing diagrams, and OmniPlan is an astounding accomplishment, a triumph of interface ingenuity and the first project management application I’ve come even close to comprehending. I’ve little doubt, and much hope, that the same standards of excellence can be applied to OmniFocus; when OmniFocus has
the fluid usability of Omni’s other applications, I’ll be eager to recommend it.
OmniFocus costs $79.95. It requires Mac OS X 10.4.8 or later; a trial version is available as a 6.7 MB download.