I’m a daily user of OmniFocus (on both iOS platforms as well as the Mac) and as a tester of the test version of OmniFocus 2 I was interested to see Chris Sauvé’s mock-ups of what he would like to see for OmniFocus 2. What was more interesting to me was his discussion of why he created the mock-ups. While the dicussion was interesting I think Chris has a misunderstanding of how GTD works, or is following the book a bit too much to the letter, and his suggestions would complicate how OmnifFocus, which was written for GTD practitioners, functions.
When discussing dates Chris says:
OmniFocus does an incredible job of modeling a certain style of thinking: the concepts of next actions, project groups, sequential and parallel projects, and folders combine to provide a rational, goal-oriented tool for completing tasks. However, dates are one of two areas (the other being context) where I feel the Omni Group has missed the mark and where makeshift solutions from the OmniFocus community have been leaned on for far too long.
He is correct, OmniFocus does do an incredible job of modeling a certain style of thinking: the GTD style of thinking. He feels that the OmniGroup missed the mark on dates and contexts which I couldn’t disagree with more.
About start dates he notes:
I believe their name implies that they are the first time that a task becomes available
That is exactly what they do and a quick trip to the help file would clarify this. The use of the start date in OmniFocus is the way that a user can implement a tickler file. He goes on to say:
What start dates have often been co-opted into, though, is a role for which they are just as ill suited as due dates: planning. If you want a particular task to surface on a particular day, what do you do? For many, this involves setting the start date
Again this is exactly how start dates are supposed to be used in OmniFocus. The point of a start date is to make sure that a task doesn’t appear until a given date. If you know you can’t work on something until a specific date then set a start date and it will be out of sight and out of mind until it needs to be. This is part of having a “trusted system” in GTD.
Chris goes on to discuss how task viewability is affected by start dates and here is where I think he should be using the tools that OmniFocus aleady provides instead of adding on more functionality. He says:
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. It’s an additional layer of complexity, but it would be worth it to allow tasks to be scheduled without removing your ability to happen upon and complete them prior to when you had originally planned to do so.
To reiterate yet again: the point of the start date in OmniFocus is to make sure that tasks that can’t be done until a certain date don’t show up in your lists. When you set a start date it shouldn’t be available. He is frustrated because he’s trying to use start dates for something they were never designed to do. He wants to add yet another date to the system to accomplish his task yet OmniFocus already has what he needs and doesn’t require adding yet another date into the equation. That feature is filtering (and at a higher level Perspectives which allow you to create preset filters that are easy to get to). If a task has a start date in the future it is not available to work on. However if there is a need to see those tasks the simple answer is to use the Availability filter.
OmniFocus is written for a GTD workflow. It wasn’t designed for someone in the planning mindset where a tool like MS Project or a todo app with a different date design might be a better fit. GTD is less about doing things by date vs. doing things based on the current situation in which you find yourself. Certainly everyone has things that need to be done by a certain date and GTD works fine in with those. But the key to GTD is to really limit setting due dates on things. If you set a due date you’re setting a hard contract with yourself. People make the mistake of trying to set dates for everything when most things don’t need a due date.
The other area where I think Chris is misunderstanding how GTD works, and how OmniFocus is designed, is when discussing changes to how contexts should work. He says:
contexts are frustratingly limited. A task can have a single context, and no more
But then he says:
In another way, though, contexts actually are flexible: they have no defined meaning, so you can set them up to be anything you’d like. Traditional contexts like Mac, Home, and Office are the defaults (and, in fact, are still my personal preference), but there has been a lot of experimentation; no contexts, energy-based contexts, priority-based contexts, and more have been floating around the OmniFocus community without much traction. It seems as though we, the OmniFocus community, aren’t really sure how they should be used. Therein lies the problem: uncertainty breeds fiddliness, particularly amongst the kinds of people who would be attracted to OmniFocus in the first place. And, as we all know, fiddliness is far from conducive to productivity.
The thing is contexts can be anything you want them to be and people seem to make that into a problem. When the Getting Things Done book was originally written it made sense to have contexts like “Home Computer”, “Work Computer”, “Office Phone”, etc. That was 2002, with the material being worked on even earlier than that. It was a different time when we didn’t have constant connectivity. I think the reason why Chris sees so much fiddling with contexts isn’t because contexts themselves are the issue, it’s because the old idea of context doesn’t really fit as much anymore and people are trying to find new ways of working.
In my own experience I still have contexts for Work and Home but Phone? No…I always have a phone with me. If I need to make a call its usually either when I’m at work or at home so those types of things go into one of those contexts. I still have an Errands context. But I have more specific situations that I find myself in that I created contexts for. I have a “financial” context for items when I sit down to look at the family finances. I have a “review” context for items that I need to deal with during a daily or weekly review. I don’t have many more than that. I think it’s a problem if your set of contexts starts to explode. That definitely is being fiddly but that isn’t the fault of the context, it’s the fault of the person perhaps overanalyzing things.
I also take advantage on occasion of not setting a context at all. If something can truly be done anywhere why do I need a context for it? It’s easier, in my mind, to not set a context vs. having a large list of fined-grained contexts that hardly ever get used and just need maintenance during a weekly review.
Chris suggests using tags which I find to be a lot more fiddly than anything related to contexts. His first example is:
You have three devices, an iPhone, an iPad, and a Mac. You can accomplish certain tasks using some subset of those devices; for example, you can only make calls on the phone, you can do your weekly OmniFocus review on the Mac or iPad, and you can take screenshots for a post on iOS 7 only on the iPhone or iPad. Using tags, you need only three contexts, which you mix and match as you please. Using one-context-only, as is the current implementation in OmniFocus, you need eight contexts to cover every alternative.
I think he’s being far too fiddly here and tags won’t fix that. You do not need eight contexts to fix this problem. One context is still enough. Or depending on the situation no context at all. For his example of doing a review….do as I do and use a single Review context. For the example of taking screenshots for a post on iOS 7…do you really not know where that will happen? When you’re doing those screenshots you probably are in the frame of reference of writing the post….use a Writing context instead of “iPhone”, “iPad”, and “Mac”. There is no need to associate a context with a place or piece of technology. It can be anything you want so associate it with a workflow or a frame of mind. I think the solution here is to rethink and reframe the set of contexts you are actually using and how things should be assigned to contexts. By using “frame of reference” contexts assigning things becomes easy.
Even thought I didn’t agree with many of the things he said, I think Chris put a lot of thought into his post and it was a good read. I love reading articles like his and he obviously cares about the subject a good deal because he put a lot of time and effort, not only into his post, but the website he created to show his designs of how he thinks OmniFocus should look and function. It was great work!