In my mind, there are three types of task scheduling which I denote as A, B, and C. ‘A’ tasks are those that have hard deadlines; they can’t be delayed without consequences. These can comprise tasks that are important to life goals such as school assignments, but they can also be mundane tasks such as paying bills. B tasks are tasks that are important to complete but they don’t inherently have any sort of immediacy to them nor is there a concrete due date that they need to be completed by. But because of their importance, you don’t want to lose forget to do them so you give them “due dates” that can be reschedule as needed. C tasks are essentially “someday/maybe” tasks and don’t get scheduled.
Currently in OmniFocus, I indicate A tasks with a flag and due date, B tasks with just a due date and no flag, and C tasks with no flag and no due date. That seems to work for me.
What I’m struggling with however is finding an elegant way in OmniFocus to denote what I might call “try dates” for A and B tasks. The due date is not necessarily the day that is best to complete the task, it’s merely the latest that it can be completed. A task might not be due until Friday, but it would be best to complete it on say Wednesday or Thursday for instance.
The first solution I came up with was to use the Defer Date field to denote when a task should be completed. It sort of works except that if I don’t complete a task on the day I deferred it and I forget to reschedule its defer date, it will completely disappear off the Forecast view the next day and not reappear until the day it’s actually due. And I’d rather use the Defer Date to indicate the soonest a task can be begun or considered available rather than when it should attempted to be completed.
Obviously I wish OmniFocus had a third date field to clearly denote “try” dates and maybe it will in the future (I sent this suggestion to Omni team). In meantime however, do you have any suggestions for how one might best distinguish between “try” and “due” dates in OmniFocus?
This is one of the use cases we had in mind for the Forecast tag: “I want to do this but it doesn’t have a hard due date so just show it to me every day until I do it”. Unfortunately it doesn’t scale out in time very well; you probably wouldn’t want to apply that Tag several months in advance, or if you did, you’d want to use it in combination with a Defer date to keep it out of your way for a while.
The forecast tag is nice. I tend to use it for miscellaneous ‘B’ tasks that aren’t important enough to pin down to a single day.
I experience a lot of anxiety from scheduling ambiguity. With a medium to large project if I don’t assign a specific ‘try’ date to each project task I lose confidence in my ability to finish the project on time. I need to plot the tasks chronologically and visually see how it can all work successfully beforehand for me to fully commit to starting and continuing the project. This is why for my most complex projects I’ve begun recently supplementing OmniFocus with OmniPlan.
The tripartite scheduling system I’m imagining can be summarized as can, should, and must.
To me, the Defer Date means “this is when a task can be done” and the Due Date means “this is when a task must be completed by”. In between I wish there was some field that could mean “this is when a task should be done”.
Ideally I’d like to keep the Defer Date purely to denote the earliest a task can be started (not when it should be completed) because if I’m running ahead of schedule I don’t want remaining tasks that I can do now to be hidden from view because I had to conflate can and should tasks.
Hi, Sheridan. I think the problem is taxonomy, because you’re not talking about soft due dates here. If some bigger item with a hard due date falls over when a smaller item without one is incomplete, that’s not soft. In my book, I call these “firm” due dates—and I repeat GTD’s advice about never using soft due dates at all, because they only serve to obscure firm and hard ones.
As for noting which is which, you’re right that that’s helpful—so in my OF, everything with a due date is also tagged Firm, Hard, RFirm, or RHard, the latter two meaning recurring. Then I tackle them in order of Hard, RHard, Firm, RFirm, because individual due dates are likely to be more crucial (although all hard dates are at least somewhat crucial, or they’re not hard).
Though I understand your needs I wouldn’t want the interface to get more cluttered with yet more date fields. For me it works just to include the final (hard) deadline in the name (of the project or action – whichever works best for that project/action) and schedule the due date as the one I want to aim to do. As long as you are consistent and ONLY use that taxonomy for the ultimate hard deadline. So when it comes up on that due day that I set in OF, I know instantly that it can slip if I can’t get to it that day (because the name says what day it’s actually due to the client). Eg, I promised the client I would have a PDF to them on Fri 10/25 so that action would be “Send revised PDF to client (DUE 10/25)” and I would schedule the OF Due Date for Wed 10/23. On Wed 10/25 I can see if I have time to do it or move it back a day.
PS I tend not to use the deferred date field – it kind of scares me when it disappears! I’m sure that’s a function of not really understanding it very well and what search functions show it and what don’t.Maybe one day I’ll get a handle on it.
Eventually, you’ll find a use for it. Otherwise, if you don’t need it yet, don’t worry about it.
For me, I don’t want to see “Submit my 1040 taxes on April 15th” until January 5th of each year. When I complete it hopefully on or before April 15th, I won’t see it for the rest of the year.
I use a combination of forecast tag (if I want to do it today) or flagging (for stuff important enough that I want to see them all the time). The hard part is not over-using these, which will lead to too much noise.
So I’ve been trying that technique for a week and it works quite well. I prepend the subtask with “↓(mm.dd.yy)” which contains the actual due date and follow it with the parent task title verbatim. I then give the subtask an earlier due date.
