One of the OmniFocus features that not too many people either need or explore much is the ability to create Context Hierarchies. You can have a Context inside a Context inside a Context inside a … you get it. So why would you need that? To be perfectly clear: You may not need this at all. However, it can come in handy as the following use cases will demonstrate. In particular if you are planning to build some useful Perspectives in OmniFocus giving the structure and Hierarchy of your Contexts some good thought is key.

While you generally should aim to keep the number of Contexts as low as possible, Hierarchies help you to manage that little complexity that you actually may need. For example you may need an individual ‘Agenda’ Context for every key person you interact with. Or one Context per location you shop at, like described in the next section. Managing this additional level of granularity is what Context Hierarchies are good at.

Location Context Hierarchies

While GTD® always had the concept of Contexts that group actions you can only complete at a specific location, the true compelling event was the introduction of the geo-fencing functionality in OmniFocus’ iOS versions. Ever since you can chose to be reminded of specific tasks when you are near or at a specific locations. That location is associated with a particular Context. Whether or not you use the geo-fencing feature you can approach location specific Contexts in three ways:

  1. Just create as many as you need on the Context root level
  2. Group them all into one ‘Locations’ Contexts branch
  3. Arrange them by geographical proximity

Location-ContextsOption 1 and 2 are pretty self-explanatory and straight forward whereby option 1 will start to get messy if you have more than a couple of location Contexts. It is option 3 that needs some explanation:

I work in mainly three locations: In my home office, at our corporate office downtown and on the go around Europe. If I am at home I may have the chance to do some groceries when I take a break from starring at a screen. When I am downtown in the office, I have the opportunity to pick up some dry cleaning during my lunch break. But when I am travelling I can typically only do stuff that you can do or get practically anywhere (read ‘Airport Shops’).

At the same time there are still, even in the digital world we live in, some office tasks I can only do in specific physical locations. I can only pick up my snail mail from my inbox at the downtown office and it is also the only place to drop my envelopes with my expense receipts. Recording screencasts for my book can only happen in my home office as my Røde Podcaster mic is installed at the desk there. Other tasks, such as printing something off, I can do in any location that offers a printer like other offices, customer sites or business centres in hotels.

Consequently I have group location Contexts that are in proximity to each other, such as downtown office and downtown errands, under one root level Context. In this example ‘Downtown’ or in my specific case ‘Stuttgart’.

People or Agenda Context Hierarchies

The concept of ‘Agenda’ Context lists is nothing new to those of you following the Getting Things Done® methodology. It is a single place to keep all the topics you like or need to discuss with a particular individual or at a regular meeting. Again, in OmniFocus, you can chose to create these Contexts on the top level which will work just fine if you do not have more than a couple of them.

Agendas-ContextsYou can also group them under one ‘Agenda’ or ‘People’ root level Context. The latter is what most people, including myself do. However, I came to refine that approach slightly over the years. Initially I realised that I missed a place to capture topics I wanted to address in one of the many regular meetings/calls I am having.

There are two different ways, none better than the other, you can incorporate meetings into your Agenda Context Hierarchy:

  1. By functional group: If you tend to meet a group from the same part of your organisation or a group of people who have the same functional role on a regular basis, but you also talk to individuals of that group frequently. Pretty good example is your team, assuming you are a manager, which you’ll talk to 1:1 with individual members, but also have regular team calls or meetings with the entire group.
  2. As a meetings group: This is more suitable if most of the meetings/calls you are attending on a regular basis are of cross-functional nature, i.e. involving people from different parts of your organisation with different roles.

Lets assume you are interacting with the Business Operations group frequently and hence you have a bi-monthly review meeting with them. But you are also talking to Sue and Benjamin of that group at least once a week concerning the on-going, more operational topics. For this use case I would like to suggest to implement a functional group Context Hierarchy:

  • Business Operations (Review Meeting)

    • Sue
    • Benjamin

Naming on the Context should work for you and your thinking pattern. You could go with just ‘Business Operations’ if that is where you would look for topics you captured for the bi-monthly review meeting. You could also call it ‘Business Operations Review Meeting’ if it does not break your head that there are Context for individual people below that. The option I used in the above example is obviously the compromise. Discussing the naming of Contexts might be about semantics, but semantics at times make a huge difference to some people’s productivity.

You can certainly also combine the two different approaches as you’ll see in the example of my people/meeting agenda Contexts. I have my direct team grouped under the ‘Team (Call)’ Context, where meetings I attend on a regular basis, that have either a more cross-functional character or happen with a group of people with whom I do not interact with individually on a regular basis, are in a separate ‘Meetings’ Context group.

Tools Context Hierarchies

Our tools become more and more ubiquitous and our data is equally accessible for everywhere. This gives you great freedom in terms of where you work on a task. You could be at you office desk in front of your laptop or sitting in some nice coffee shop with your iPad in front of you. The likelihood of having the right applications and data available in both scenarios is pretty high. However, there are still a number of task you can only do with in a specific setup. Some tasks can also be completed in a more comfortable way on your laptop compared to your tablet for example.

Computer-ContextsPivot tables is still something you need your big machine for, the more complex features of Photoshop are only available on the Mac OS X version and designing a magazine layout is likely better done on your iMac and with InDesign. But writing an email, outlining the flow of your Business Review presentation or reviewing last months family pictures can be done on your iPad (or at your laptop).

The way I solved this for myself is to group my iPad and my MacBook Air (MBA) under a ‘Computer’ Context. Those tasks that can only be done on specific device (e.g. Data analysis using Pivot tables) end up in the corresponding sub-Context and those I can do on any device are assigned to the root level ‘Computer’ Context.

If your work is mainly centred around some key applications you could go as far as creating Contexts for those as well. Just make sure you are not creating a structure that becomes unmanageable or you only master if you are at the top of your game. These action lists (and that is what Contexts really are) need to still work even if you are in a Zombie-like condition.

Golden Rules for Contexts

In order to help you to not get too wild I suggest you consider the following two Golden Rules for Contexts.

  1. A Context should always have more than two actions assigned to it. You can create 40 Context lists, but if you are not using 30 of them on a regular basis you are doing it wrong and likely created a monster that keeps you busy maintaining it rather than helping you get stuff done.
  2. Use Context and Context Hierarchies that match your thinking pattern. There are lot of great examples for Contexts out there (and in this post), but they will not help you at all if your brain is wired in a different way. In one of my most popular posts about A Fresh Take on Context I have reflected on how some of us and some of the jobs we perform fundamentally change the way we evaluate what to do next.

Should you need a more general introduction to Contexts in OmniFocus first, I'd like to recommend starting with the Defining and Managing Contexts post.

If you have good examples of Context Hierarchies you are using please share them!