I use the word “context” very loosely. The way I see it, GTD was designed for an entirely different kind of animal than you and I. Where someone in middle management might parcel up their day into physical contexts like “phone,” and “computer,” and so on, there are just too many things that creatives do that are mood based and so on. I think the key is to look at how contexts can be used in the framework of the application, and then design it around how you work.
For example, when I’m editing I’m in an entirely different frame of mind than when I’m doing creative writing, and that is different than when writing non-fiction. But that doesn’t mean these make good contexts. They might for some people—again it all depends on how you work.
I do have some traditional physical contexts. Things that need to be done around the house, for instance. Things that require running to the store. I also have some “state based” context, such as “Expand” and “Maybe.” This lets me focus the interface on things that need to be done inside the list as well, or to just see things that I’d like to do but have deemed not worth it at the moment.
Just look at Contexts for what they are in OmniFocus. They are a way of applying a topical filter to tasks that transcends the “project” hierarchy. A way to single out things regardless of what area of responsibility, and get them done according to present state and frame of mind.
This is kind of the idea behind GTD that sets it apart from other productivity philosophies. The notion that tasks should be approached from a different angle than projects, and completed almost regardless of the project. If you are at home, you might touch five different projects by completing five tasks, but in doing that you’ve moved five projects forward where if you had just focused on one project in a linear fashion, the chances of getting hung up and not actually getting as much done are higher. It is a good way to go if you have a lot of things going on at once, and find it hard to keep them all moving forward.
The key thing that trips a lot of people up is that this way of doing things by context will utterly fail if tasks are too complicated. One of the first things the book covers is how to recognise a complicated task and break it up into a “project,” what you can use nested outlined tasks for in OF. The rule of thumb is: A task should be something you can do in one sitting, without a lot of “getting in to it.” If preparation is required to start a task, then that preparation should be broken up into different tasks, with the final task being setting up the prepared material in such a way that the next action can naturally flow right off of it, without any preparation.
That is the theory anyway. How well it works for you is up to you, and OF is flexible enough that it doesn’t dictate this philosophy, it merely allows it in a way that I find more fluid than other GTD programs I’ve tried. The outliner method is great for taking a complex task and chopping it up.
