Next post Previous post

Looking at OmniFocus

August 14, 2008 at 4:07 PM by Dr. Drang

A couple of weeks ago on the Macbreak Weekly podcast, Andy Ihnatko said that he didn’t understand OmniFocus. It seemed wrong to him that tasks he’d just entered didn’t appear in his task list. I’ve read other complaints about this same thing, and when I was first using OmniFocus I also sometimes found myself confused about the whys and wherefores of task visibility. In this post, I’m going to:

Before going further, let me mention that I don’t work for Omni and have no insider knowledge about the program. Everything I say here is based strictly on my use of the program.

To understand OmniFocus, you must realize that it is not an application for making lists—if you want to make lists, you can use OmniOutliner or Opal or TextEdit or Pages or Numbers or, really, any application that lets you type in lines of text. The purpose of OmniFocus lies in the second half of its name: it’s designed to help you focus on your tasks, and it does that by hiding tasks that are not relevant to your current situation. It decides what to show and what to hide based on three things: the Context, the Project Type, and the Action View.

OmniFocus defines Contexts in exactly the same way as David Allen does in Getting Things Done. What you can and cannot do at any given time is determined by where you are and the tools you have at hand. That is your Context. You cannot, for example seal the grout in your shower when you’re at work, so “Seal shower grout” is not a task you should be looking at in the office1. OmniFocus lets you define whatever Contexts are appropriate for your life and assign one of those Contexts to each of your tasks. When you are in Context Mode, clicking the name of a Context will cause OmniFocus to show only those tasks assigned that Context.

There are two Project Types: sequential and parallel. The tasks in a sequential project have to be done in a particular order; the tasks in a parallel project can be done in any order. Here’s a sequential project from my OmniFocus database:

The project is identified as sequential by the two little tip-to-tail arrows. Clearly, I can’t install the fan until I have the fan and all the necessary auxiliary equipment.

Here’s a parallel project

where the stacked arrows identify it as parallel. I can do these two tasks in either order. The archetypal parallel project is probably the shopping list.

When you create a new project, OmniFocus will set it to be either sequential or parallel, depending on a setting in its preferences. You can change from one to the other by clicking arrows icon. The Project Type doesn’t have a direct, independent effect on the visibility of a task, but does affect it visibility in conjunction with the Action View.

Omni doesn’t seem to have an official name for what I call Action View, so I’d better start with an explanation. By Action View, I mean the setting you get from this menu in the View Bar:

As you can see, when you are in Context Mode, four Action Views are possible:

Since we’re in Context Mode, the word “all” in the above descriptions means “all in the current Context.”

The visibility of tasks in a given Context depend to some extent on the interaction between the Project Type and the Action View.

Action View Project Type Visible tasks
Remaining Sequential Uncompleted
Remaining Parallel Uncompleted
Due Soon Sequential Uncompleted and due within 2 days
Due Soon Parallel Uncompleted and due within 2 days
Next Action Sequential Uncompleted at the top of their project task list
Next Action Parallel Uncompleted at the top of their project task list
Available Sequential Uncompleted at the top of their project task list
Available Parallel Uncompleted
Completed Sequential Completed
Completed Parallel Completed

At first glance, this table may seem to be just a rehash of the earlier list of Action Views, but there’s one difference: the visible tasks for an Action View of Available depend on the Project Type. When the Project Type is sequential, Available works like Next Action. When the Project Type is parallel, Available works like Remaining.

If you think about it a bit, this makes sense. In a sequential project, you cannot do the second or later tasks until the first task is done, you cannot do the third and later task until the second is done, and so on. Therefore, only the top uncompleted task is “available” for you to do, which is why Available works like Next Action (“action” is a GTD word that’s identical to “task”). In a parallel project, on the other hand, every uncompleted task is “available” at any time, so Available works like Remaining.

Once I understood how it worked, Available became my normal Action View in Context Mode, because the Next Action is the right thing to focus on in a sequential project, and all Remaining actions should be considered in a parallel project. The one exception is the Waiting context—there I want to see all Remaining tasks no matter what type of project they belong to.

In Project Mode, there is another set of Action Views available:

In Project Mode “all” means “all in the currently selected project.” The interaction between Project Type and Action View is similar to that in Context Mode:

Action View Project Type Visible tasks
Any Status Sequential All tasks
Any Status Parallel All tasks
Remaining Sequential Uncompleted
Remaining Parallel Uncompleted
Next Action Sequential Uncompleted at the top of their project task list
Next Action Parallel Uncompleted at the top of their project task list
Available Sequential Uncompleted at the top of their project task list
Available Parallel Uncompleted
Completed Sequential Completed
Completed Parallel Completed

As in Context Mode, task visibility depends on Project Type only for the Available Action View. Project Mode has two unique visibility features:

  1. You see completed and uncompleted tasks at the same time.
  2. Tasks with a Context of Waiting are visible only with an Action View of Any Status or Remaining, regardless of the Project Type.

The latter feature makes Waiting tasks different from all the others with regard to the Available Action View. I guess Omni’s perspective on this is that something you’re Waiting for can’t be Available, which makes sense, even though it breaks consistency with other Contexts.

So, with all these interactions conspiring—rightly—to hide tasks from you, it’s no surprise that people are bewildered by their “missing” tasks when they first start using OmniFocus. There is a relatively simple way to see all Remaining tasks in all Contexts, but it’s hidden. You have to make the View Bar visible, then select All Contexts from the menu at the far left and Remaining from the Action View menu. If Omni created a button that would activate these settings with a single click and put that button in the in the toolbar where it would always be visible, I think it would help new users get acclimated to the OmniFocus way.

(Yes, I know you can create your own button that will do this by using Perspectives, but that’s too much to ask of a brand new user.)

Larry Wall, the creator of Perl, has written that he wanted in Perl to be like natural languages in the way new users could write useful programs very early on, before they attained fluency. A five-year-old doesn’t speak English like an adult, and often says things that adults think are funny and cute, but he still communicates. The same is true of non-native speakers who are just learning the language. Wall wanted Perl to be like that, and is probably most proud of how close it is to that ideal.

I think Omni should strive for the same ideal in OmniFocus. New users—and we’re all new users—are going to be coming from paper-and-pen lists or more elementary to-do list software, and the richness and “otherness” of OmniFocus is going to be offputting unless Omni can make it easier for users to get things done while still speaking baby-talk.

One more thing: OmniFocus for the iPhone forces you to choose your Action View in the Settings screen:

If you’re looking at your tasks in Context Mode and want to change the Action View, you have to go all the way back to the home screen, into Settings, change the Action View, back to home, then to Contexts, and finally to the specific Context you were originally at. This is ridiculous. Changing the Action View should be done through a menu that pops up from the toolbar.

The problem is the Waiting context—if I didn’t Waiting tasks, I’d just keep the setting at Available. But because I use Waiting to keep track of documents, reports, email, and phone calls that people owe me, I need to check the Waiting context fairly often. And because the Waiting context won’t show any tasks unless the Action View is set to Remaining, I have to keep switching the Action View back and forth between Available and Remaining. In the Mac version, I have Perspectives set up to handle this switching with a single click, but since the iPhone version doesn’t have Perspectives, I’m forced to do this intricate dance between screens.

As I was writing this post, I noticed a bug in how OmniFocus handles due dates in sequential projects. I’ve never noticed it before, because I seldom use due dates. It’ll have to wait for a later post.

Update
Ken Case of Omni Twittered me with an explanation of the Waiting difference:

If you want the Waiting context to behave exactly like other contexts, you can change its status from “On Hold” to “Active”.

I knew that Waiting was a unique Context because it’s built-in—you don’t have to create it. I didn’t realize it had a different status. In fact, I didn’t think contexts could have a status of On Hold, only projects. Of course, this means Status is a fourth element that determines whether a task is visible.

Tags:

  1. I’m assuming here that you’re trying to accomplish your listed tasks, not plan new projects. Planning can be done pretty much anywhere. ↩

Next post Previous post