31.1.13. Refining my Work Contexts in OmniFocus

Contexts are a major component in the GTD system by David Allen, and thus figure prominently in OmniFocus. Understanding and working well within contexts is an ongoing process. Some are immediately understandable, such as "Grocery Store" or "Home". Some may be devices, such as "Phone". These are known physical limitations where an action can only be performed in that physical space or device.

My life doesn't involve a lot of physical contexts outside of errands (then grouped by a couple of common errand types, and then by store for anything really specific), home, and work. But 'Work' is where I do and use much of my planning. I found that just having that as a lone context didn't work for me. Years ago, I set up two sub-contexts, Coding and Office and that got me by for a while, with most work tasks being in Work : Coding. This is still the case today, but I've recently found that it's helped to create some additional contexts that revolve around tools and responsibilities.

My work sub-contexts:

• Coding, wherein I do most of my work. This is the editor - terminal - browser cycle, usually. For the longest time, this context was synonymous with "@work", as it was, well, what I did.
• Deployment, a newly created context. This also tends to involve the terminal, but doesn't really depend on the editor or other bits. It tends to mean kicking off some automated scripts and keeping an eye on them. I separated it out into its own context so that I could see these separately from all of the potential coding "next actions", as deployments may have a higher or different priority. For example, I can deploy while eating lunch at my desk, so I might let these pile up from various other projects.
• Research. The actions in here vary, but being in this context often signifies needing to crawl through code, archives, or the internet to learn something new or be reminded of how something works.
• Basecamp, for needing to interact with the Basecamp project management system. The actions for this could mean just marking a task assignment as complete, or it could mean needing to write a message or comment to communicate with the team. I found that these kinds of actions were starting to slip from my head.
• Agenda for anything I need to bring up at a meeting.
• Documentation for tasks needing a bit of extra focus for writing and publishing.
• Office for anything generic that can only be done at the office. This might mean something that requires a printer (I have none at home), or it might mean something I need to pick up or drop off at the office.

The nice side of this is that I can just park OmniFocus on my iPad in the "Work" context and see the available actions in all of these sub-contexts. The context they're in might let me know the time or tools involved, and that can help me make decisions about what to do next when I have multiple things happening at or near the same time. For example, I met let a couple of deployment tasks queue up, or I can do a deployment task while working on another project's coding task, as deployment requires little physical or mental labor but may require a lot of watching and waiting for changes to roll out across our servers. My Basecamp tasks can queue up for the end of the day, and have been helpful in reminding me to update our central project system used for company communication.

There seem to be some people these days wanting "multiple context assignment" in OmniFocus. I do not. I'm happy with the hierarchical context system. When in work mode, I can choose the level at which I want to focus and tune other things out. OmniFocus's hierarchical contexts also make re-organization easy without losing assignment. If a certain hierarchy isn't working out, I can change it with some dragging and dropping. This has helped keep my system functioning for me as my needs and expectations have evolved over the years.