Multiple Contexts per Task [now in TestFlight]

I’m surprised that nobody has mentioned that OmniFocus already supports groups of contexts! Just drag a context inside another context to create your hierarchy. Here’s a screenshot from the documentation:

2 Likes

I use that all the time. The only issue I am clumsy with about it is some tasks I can do on foot and others require a car, and they’re not always the same location.

e.g. Sometimes in my @Errands I have a task that involves shopping at a specific store. If it’s a little thing, like getting a toy for my kid, I can do that on foot and take the bus while I’m at work. But other times it’s a larger item or perishable and I need the car for that.

I’ve tried duplicating contexts into a @Car branch but that gets confusing sometimes when I’m assigning, and sometimes it could be either car or no-car. In those cases a @Car is required but there are a lot of errands and tasks around town that don’t require a @Car, and then I’m also thinking my @City and @Neighboring\ City contexts aren’t the right way to structure those errands either. I suspect I shouldn’t be creating contexts for specific places in most of these cases but I haven’t spent time agonizing over it. Yet.

If you search the forum, you will find a few discussions about multiple contexts. Omnigroup is planning on implementing multiple conte to or tags of some sort.

Adding multiple contexts or tags sounds like a simple thing to do but it will have a large ripple effect on everything else. I think they are trying out different user interfaces to figure this out. This will affect the Mac, iPhone, iPad, and Apple watch

It is waiting in their secret lab somewhere. If you have ideas and mockups, you can always email them to submit your creations.

Yes, I know OF philosophy is against using multiple contexts. But let’s face it: time changes everything. Contexts per se are kind of obsolete now. I also understand OF foundation follows the GTD methodology.
But many users (me included) think differently. I don’t care what GTD methodology says. I just want a task manager that helps me to better organize my time.
I’m really sad about OmniGroup answering time after time that multiple context (or whatever this should be named) is against OF foundation. Usually, software companies try to make their customers happy and make big efforts to keep them away from leaving and moving into other options. But for some reason, it looks like if OmniGroup had the truth about the right way to manage my day.
This sounds to me a little arrogant. I truly apologize for such a rude statement, but it is my sincere perception. Why not let the users to decide what better works for them? Why to defend a philosophy that clearly is not making happy to many users?
I like OF. A lot. I just can’t understand this. Giving the option to the customers can’t be bad.

I’ve seen a few time times that people state that “multiple contexts is against GTD”, but can anyone cite where that is?

I’ve studied GTD for over a decade, and have never encountered anything that says you can’t have multiple contexts. Rather, the point is for lists to have meaning so that available tasks are able to be surfaced and unavailable tasks are not (then you do based on priority, energy, and perceived payoff). That’s really what it’s about. For some people, I can totally see why multiple contexts would make sense to enable that (i.e. a task that can occur under more than one condition, but not universally).

I would love to understand if there really is a specific GTD guidance against multiple contexts and what its rationale is. Can someone cite a book page number or other resource, or is this an internet-assumed piece of GTD lore?

Thanks!

ScottyJ

2 Likes

Awesome idea! It would be great addition. Todo it’s which is in my opinion omnifocus biggest compedator has inplimented “tags” which is the number one reason why people make the switch. It would be good to see omnifocus adopt tags

I think the reason for quoting multiple tags as un-GTD is not explicitly formulated in the book. That said David Allen uses every chance to actively reject the use of tags due to reduced focus and no necessity to be clear about the context the task is going to need.

I would say exactly the opposite to

I would say the willful limitation on one focus is currently a feature putting OF apart from all others bluntly enabling tags.

I know Omnifocus (rep) stated the same thing about there being more than one context means that you haven’t fully broken the task to its core which is to say a person hasn’t gotten clear 100% and still needs to be processed.

I guess what I meant to say is to add the feature tagging (not multiple context) although similar in use. Tagging is used to help manage and filtrate information while context remains its full purpose. Which is a person, place or thing in order to be completed.

Adding both may seem little big cumbersome however, there are benefits to both. Context should be limited to one, used for geo-location. Contexts benefit is also its limitation which is the ridgity. Meaning, to have one context so it doesn’t confuse however, a lot of the time the strict hierarchy can be complicated to work through and interrupt flow by spending more time fiddling than doing.

Tagging should be color and hierarchy based, have ability to add multiple tags to an action to help categorize and organize inputs.

2 Likes

Sounds like some middle ground there… I like the idea!

Like context is good for braking a task to its most basic form. And very good at it to.

But tags are more flexible. For example, tagging a task based on priority, energy level and even type of hat (personal label one gives themselves to help facilitate and carry out the type of work they do), would all be examples of efficient labeling. Now try and take the same scenario into a context form, and it’s utter chaos. Even with perspectives, it is not possible to get the effect of the hybrid (tagging / context feature) we are requesting.

3 Likes

@mat_rhein Yes, I heard the objection to tags, but it comes across as an implementation problem, and not as fundamentally counter-GTD (the framework itself) idea.

I think it comes down to how contexts are set up. In the past, I had contexts called Mac and iPad, referring to things I could do on either of the platforms, but of course there are numerous things I could do on either.

Likewise, my next action migh be about “ask for clarification on the new policy”, in which I know both my boss, his boss, and one of his peers are expert. I’d like it to be an in-person conversation, because it could be a bit complex, but it isn’t urgent and could be with whomever I run in to first, so technically, there are three possible contexts to which this belong.

I’m personally fine with one context - I’ve used OF/kGTD long enough, but I understand the use case.

I definitely hear what you’re saying, though, and certainly there is an inherent risk to being dilutive of the discipline by opening things up too much.

Cheers,

ScottyJ

1 Like

I could not agree more!

Should definitely be added as part of making Omnifocus less (taxonomically) restrictive. A task could even belong to many projects… What would be great would be some sort of free-form tagging system with ‘tag groups’, where some of these, like context, were special. Many-to-many all over the place.

Implementation-wise, It seems that every OMNIFOCUS task can have only one each of 2 classes of 'hierarchical tags ’ ( it REALLY is what they are in reality) and can’t have multiple ones of any of the 2 classes. ( I’m ignoring other metadata such as flagged/unflagged, deferred to one date vs another etc… but these are similarly designed in that a task can’t belong to more than one configuration of any class of metadata )
1: a folder:project:container-task hierarchical tag
2: a hierarchical Context tag

That’s it. Every task can only have one of each of these 2. OF2 was never designed to have multiple tags of any category, which is why to implement traditional ‘tagging’ ( multiple tags of any one type). OF would have to be redesigned from the ground up. Schema changes of this magnitude would break compatibility with Of 1, and be a huge pain to implement. The pain vs gain analysis that I’m sure the OmniGroup has done, makes it a distant priority for them since Of2 is still so popular WITHOUT tagging. . Tagging is so far away it seems that us users who are dying for TAGS might as well forget about it altogether for now. ( Good news is that the CEO has mentioned in a Twitter post a few months ago that tagging WILL be implemented within this dev. cycle, so hopefully within a year at least ). I personally use OF 2 for its looks and have resigned myself to a life without tags for now. If someone REALLY wants tags they should switch to 2do, Todoist or something like that for now.

I think the concept of tagging / allowing multiple contexts is already acknowledged by the Omnifocus team - however they are only supported hierarchically.

In David Allen’s four-criteria model for choosing actions in the moment, he outlines the following (from his book Getting Things Done : The Art of Stress Free Productivity, Chapter 2):

  1. Context
  2. Time Available
  3. Energy Available
  4. Priority

Context is only a single item in the list. Time available could be covered by Estimated Duration and/or Due, Energy Available is simply not available as a choice. In a podcast I heard mention of a ‘Context’ called ‘Low Energy’ or ‘Brain Dead’ that serve to cover these kids of tasks but that is mixing the metaphor of Energy with ‘Context’. And the Priority right now is very poorly represented in OF. It is either flagged or not, due or not. I don’t particularly like to have complex priority systems. But even MS Outlook has the possibility of Low, Normal and High priority. Again you can blend your Due Date into the Priority metaphor but you are mixing a martini here … mmm martini … the closest I have is to flag something.

Does the four-criteria model work in a hierarchical context model with some additional fields. No it does not - I have to work around the limitations of the tool to make it work.

This is why other tools that provide so-called ‘Tagging’ which is really a filing/metadata/search concept actually are functionally richer because they allow you to apply all of these criteria - either singly or in multiples to slice and dice your data.

The workaround, it seems, is a complex use of pretending that you have ‘tags’ in action notes by somehow typing them separately from other notes and then using a Pro feature of having multiple perspectives to try and make sense of what that all means.

The reason I bring this up is I have done a lot of training on OF - webinars, ebooks, elearning, and so on, and yet when it comes to the cut (currently I am working through TRO again as I am forced to use outlook in my work environment) I have a simpler and easier system to use in outlook of all places simply because I can assign multiple categories (contexts) per task. OF cannot be my main task manager because it is severely hampered by the lack of this feature.

Maybe for running my home and personal life it works fine (it does!). Maybe if I was running a small or medium size business it would work too … (it also does to a limited extent). But at the executive level of a very large organization where time is extremely limited, and given a constant and very intense email, IM, text and phone barrage every day and OF’s lack of multiple context and the ability to cut between them shows immediate problems.

I’ve been an avid follower of OF since the Omni Outliner and Kinkless GTD days. I am eager for it to work but each attempt has simply bumped into workaround after workaround.

Right now TRO at least shows a way past this. Unfortunately OF is not a tool that even works with this approach.

I would urge the consideration of at least the four-criteria model for inclusion in the product. Perspectives can then take care of the rest.

I tend to think in a different view.

  1. Context - Taken care of by OmniFocus context

  2. Time Available - using the Estimated duration and perspectives to show you what you can do within a certain time block.

  3. Energy Available - this one is hard to gauge. I haven’t quite figured how to use this in OmniFocus without resorting to the Contexts label.

  4. Priority - I use flags and due dates.

Due dates - I have my OmniFocus preference settings to indicate “Due Soon” as 1 week. When I see a task that has a yellow status circle, the priority shoots up from regular mode (low priority) to a higher mode (medium priority). I know I should be working on this yellow task within the next 7 days. If the status circle changes to red, it is overdue and I should really do this task first before anything else. The red status circle is “high” priority.

I also use flags to elevate a task from low priority (no flag, no due date) to medium priority. The orange status circle tells me that I have targeted this task as something to work on in the next few days (hopefully today). It doesn’t have a due date so i won’t be working on a flagged task until I finish all of my overdue and due soon tasks.

So we can have three perspectives:

Due perspective (high priority) - This custom perspective shows all available tasks sorted by due date. All red status tasks (overdue) will be at the top. All yellow status tasks (due soon) will be shown in the next group.

Flagged (medium priority) - I use the default flagged perspective but have it sorted by due dates. Work on these tasks only when I am comfortable with having completed as many items in due perspective first.

Available (low priority) - This custom perspective shows all available tasks sorted by due date. The red status tasks come first followed by yellow tasks, and then the low priority tasks are shown in light gray.

I like to use the different data fields and different perspectives to show me all of my high priority tasks, medium priority tasks, and low priority tasks.

Agreed but Energy is still missing and it is part of the Four Category model. It sounds pedantic and to some extent it is. Similar to Extreme programming the idea is not to cut every idea or practice. It is to use the minimal set of what works. So at least here is one item of that de minimis set (stated by GTD) that is missing from the product.

Having to mess around with Dates to indicate priority really is not GTD - it is a hack. Is it due today, tomorrow, next week or in a tickler file. Sure I can type all of these in but I then end up with a Due Date that says ‘Bad Things will happen if I don’t complete on this date’ whereas I may only be saying ‘I can’t get to this today’ or ‘I’ll review in my weekly review’.

Due dates should be stakes in the ground as they relate to your calendar. They should be done on that day or not done at all.

Priority has nothing to do with your calendar being subjective in the moment from one day to the next.

I have tried my best with this program but ultimately it will not work, oddly enough, with GTD.

I love some of the features - particularly perspectives - but OF is slowing me down tremendously. Onwards and upwards to something a bit more GTD like.

2 Likes

I’ve suggested both multiple contexts, but the more I think about it, a better way is tags and tag groups.

In this view, then context becomes just a specific tag group.

My simple minded analysis of the problem:

I think context originally was designed to separate areas of your work by location. You aren’t nagged to pick up milk while you are at work.

I’m a tree farmer. I have an office context and a field context that get used for most things, and a Trips context when I’m in town, with a bunch of little contexts for individual stores.

But I also run into issues where I can’t do something because a particular person isn’t here, or I can’t do something when the weather is behaving in a certain way. As I type this, I can’t transplant because it’s still dark. (6 a.m.)

Also: I know that I have way more to do than I can get done before snow flies.

Since Home versus field context is obvious, I’m no longer using it. Instead of dates now, I’m assigning priorities, where priority 1 is as soon as possible, and priority 5 is Maybe never.

I’m awful at estimating time. Sherwood’s Rule: Make the best estimate you can, then double it and use the next larger unit. If you think it will take 3 hours, it takes 6 days.

Anyway I see a tag group as being a facet for filtering. So you could define L- to be location. L-Hardware is the hardware store. L-Safeway is the grocery store. If you need lightbulbs, you can give the “Pick up Lightbulbs” both the hardware store and the safeway as L tags.

A tag group could be defined to be single or multiple, If single, then setting one, clears the previous one from that group. So, for example, if OF had the ability to have coloured flags, then setting a red flag would clear an amber flag. In my case I’d like a season tag group. Certain actions happen just after snow melt. Others just after snow sticks. Others when we’ve had a killing frost.

The hard part is the user interface for this.

I can see using multiple flag colours just to allow people another way to do things. And someway to search for all flags, or just ones of particular colours.

I’m not sure what the best way to handle generic tags however.

My errands

1 Like

How long do we have to wait to finally get Multiple contexts or Tags?
We have seen so many user requests! And in 2014 Omni Group informed us that they plan to implement (though no ETA). Now more than 2 years later, I really hope to hear more.

Many many customers have now requested it, but it does not seem to lead to any motivation for the team to listen/implement. Much time is however invested in much more obscure projects like taskpaper compatibility. Nice to have, but only requested by a small niche group of customers.

Please Omni team communicate more clearly on your real intentions, otherwise more and more users will leave to the competition like 2DO.

2 Likes

It’s not scheduled for 2016, but I hope that doesn’t come as a surprise! Each year, I post the upcoming year’s roadmap on our blog as well as on these forums. We had a very full roadmap this year which included a new file format that lays the groundwork for letting us implement this feature without breaking synchronization.

But the file format isn’t the only thing that needs to change, there are lots of assumptions throughout our interface and underlying code about one context per task and we have a lot of problems to solve as we change those assumptions. (As a simple example, what happens when you assign a context that’s on hold to a task, along with assigning a context that’s available: is that task available or not? And if multiple contexts are assigned to a task, what order should they appear in in the context field? How do you indicate whether you’re adding a context or replacing the current context? And so on.)

This feature is important to us, which is why we’ve been making steady progress towards it. But so are many other features, like global search for Mac (currently in public test) and the many other features listed (and implemented) in this year’s roadmap (style settings, dark mode, improved sync conflict resolution, encrypted sync database, iOS automation with TaskPaper templates, and supporting new operating system features like iOS 10’s interactive widgets and macOS Sierra’s tabs).

6 Likes