Chris of Pxldot[2], creator of a fantastic Applescript template for OmniFocus, wrote a two-part series of the why and how of the changes he’d like to make to OmniFocus (found courtesy of Workflowing):

• What’s Eating OmniFocus – Part 1
• What’s Eating OmniFocus – Part 2

While I cannot agree with everything he says, I totally admire the effort he’s put in. I will now, in true critic form, say what’s right and wrong about a bunch he’s said. [1]

I don’t mean to pick on his ideas specifically. But Chris has so nicely laid out a number of concerns that all touch upon several ideas I just haven’t had the time to write about, that I couldn’t pass up the opportunity.

I’d like to do this in a series of posts. Today, I’ll focus on …

“Target Dates”

Chris describes a difficulty with start dates and an interesting remedy with the use of “target dates”:

In OmniFocus, two dates can be assigned to a task or project: a start date and a due date. Due dates are clear in purpose (though some still abuse them as a result of the same issue I’m about to detail): if something has to be done by a certain date, that is the date it is due. Start dates, however, are far more ambiguous; if not in their purpose, at least in their typical usage. I believe their name implies that they are the first time that a task becomes available; for example, you can only start working on your taxes on January 1st. …

… For many, this involves setting the start date (and, if you are like me, a flagged status as well). But if you set the start date in the future, the task will no longer appear as “available”, meaning you will never be aware that they are, technically, available for you should you go through your OmniFocus lists looking for something productive to do. This situation happens to me so often, and my frustration of having to set the start date and flagged status for scheduling tasks is so pointed, that I think the single most important change in OmniFocus would be the addition of a third date: the Target/Planned date.

While I think I can see the benefit, its hard to say how it would manifest in practice. In fact, I wonder if it would confuse matters as I do believe that the functionality is already there.

The tax example he presents is a good one. One cannot do the taxes until January 1st. Having a start date of January 1st makes sense as the tasks are now available. However, I may not want to do the work until February 1st, perhaps when I anticipate more time.

One can have this using a Flag Dated core. In other words, one uses available and flagged tasks for the things to be worked on today.

Specifically, with all projects available in the library, the filter settings would be:

• Availability Filter: Available
• Status Filter: set to “Flagged” or “Due or Flagged”
• Estimated Time Filter: Any Duration

Doing so allows the tax work to become active on January 1st, but not appear in daily view until desired. In the example I propose of wanting to do the work on February 1st, I would add a task to the project that says “Begin tax project” @Laptop ; Start Date 2/1 ; Flag on.

Doing so allows the task to appear when I want it to while the other tasks remain available, but not visible to daily view. They’re just not on my daily plate until I want them to be.

In other words, the target date system is already in place. Adding another date mechanism could make an already complex program more confusing.

Note: For those who’ve read Creating Flow with OmniFocus, this does not apply to the start date based core. I increasingly find that a system centered on flags offers greater flexibility, as is evident here.

Depending upon response, I hope to continue posting thoughts in response to Chris’ excellent post …