Multiple Contexts per Task [now in TestFlight]


#153

For now, I put it into the @shopping context. Whenever I’m shopping at any one of these stores, I visit the @shopping context. For items that can only be found at one store, I will put it in the sub context.

@Shopping
@Shopping:IKEA
@Shopping:hardware store
@Shopping:discount store

I put “buy light bulbs” into @Shopping. But if there is a sale on mattresses only at IKEA, I will put “buy mattresses” into @Shopping:IKEA.

When I visit IKEA, I can visit the @Shopping context and it will also show my IKEA sub-context.

That should work for now until whenever multiple contexts gets supported.


#154

Great tip, thanks much!


#155

any news, about multiple context?

TIA

amelchi


#156

the problem is the same with Teams…
let’s say I have a meeting with my Team; it will be in my @Team context
likewise if I have something to deal with Paul will be @Team:Paul
likewise if I have something to deal with Bob will be @Team:Bob
but…
if I have to talk to Paul and Bob?

thanks

amelchi


#157

Isn’t that something you’d schedule and thus use the calendar for? You can still use a todo and say something like "discuss with " which you check off when the meeting is over.

As for the shopping contexts…I’m running into that too and wished we could also use folders in contexts and not just in projects. That way I can group all contexts that have to do with shopping. I’d also like to be able to assign a status to an action other than “active” and “complete” (something like: active, on hold, waiting, complete). Some actions take time and can’t/shouldn’t be broken down into smaller items (like solving a problem: analysing can take hours to days or even weeks; the same for finding the solution; implementing the solution could be broken down). Currently I’m (ab)using contexts for that which works fine but would work heaps better if we could assign multiple contexts.


#158

I’m not sure how this idea fits to the thread’s proposal to be able to assign multiple contexts. In any case, I like the idea of having three status states for a task: active, dropped, and complete. I really cannot agree with any others than these three. Here’s my reasoning against your others.

On Hold --> If a task is on hold, then its source project is on hold. We have this option already.

Waiting (On) --> I handle this in a “cleaner” manner. Set up two sequential tasks for a contact.

  • call Jones to schedule meeting (@contact)
  • get feedback from Jones to schedule meeting (@waiting on : Jones)

As soon as I make the call, I check off done. In your case, I might forget to toggle the task from @contact to @waiting-on and instead (mistakenly) check it done. Also, my approach has only one level of simple decision making when doing the task – check it off done. Your’s has two potentially more complicated decision steps (remember to toggle the state to … gosh … what is the toggle’s name again??? …, then later remember to … oh … do I need to toggle this state here or check it off???).

I might note that I now find the method in this thread to be an elegant way (hack) to handle tasks that have been pushed to “dropped” rather than “complete”. This is especially true since I can put the AppleScript handler appropriately as a button in the main OF toolbar.

I disagree somewhat yet agree somewhat. Solving a problem has steps …

  • Define the Problem
  • Gather Information
  • Propose Solutions (confirm it works)
  • Evaluate the Options
  • Report the Results

This is me the engineer speaking. I agree that each big step takes time. I disagree that each one cannot be further divided. I might tend to handle the flow this way …

Project (sequential)

  • Definition (parallel)
  • outline the problem statement (@propose)
  • finalize the problem statement outline (@do)
  • send off the draft problem statement to team (@deliver)
  • Research (parallel)
  • get the background info (@resesarch)
  • get feedback from team (@waiting on : team)
  • complete a formal problem statement (@tidy up)
  • Proposal (parallel)
  • outline proposed solutions (@propose)
  • test proposed solutions against inputs (@do)
  • finalize proposed solution (@tidy up)
  • send off the problem statement and proposal to team (@deliver)
  • get feedback on problem statement and proposal (@waiting on : team)
  • Result (parallel)
  • crunch the numbers (@do)
  • confirm the calculations (@do)
  • finalize the result (@tidy up)
  • prepare a formal full report (@do)
  • send the formal full report to the team (@deliver)
  • get feedback on the project (@meeting : team)
  • Complete (parallel)
  • document the conclusions (@close)
  • archive the project (@close)
  • note next actions (@close)

Contexts are one of the things in OF that I feel really should be at the liberty of the individual user to (ab)use. The objective should be to find what works best for you in your workflow.

I agree here.


JJW


#159

You can have an additional status field or you could use contexts for this. In case of the latter you definitely want multiple contexts because you can then assign a context as you normally would plus a status context that tells you the status of the task. I rather have the multiple contexts option than a separate status field as contexts are much more flexible and thus catered to much more situations. I merely gave 1 example out of many.

The status of a task is not the same as the project status and never ever should be for all types of projects. If it were the same than it would lead to very unwanted situations for projects that are type “parallel” or type “single actions” as it means that 1 single task blocks everything in that project which is completely against the entire purpose of those types. A project is “single actions” or “parallel” because the tasks can run in various order. It is only with projects of type “sequential” where you may want to put the entire project on hold when putting one task on hold.

As an example: I can have a project called “Implementing VLANs”. One of the tasks is to create a VLAN for ordinary clients and another is to create a VLAN for wireless clients. Now if there is a discussion if we should still use two separate VLANs or simply use 1 for all sorts of clients you want to put that second task on hold until the decision is made. In your logic this would stop the entire VLAN implementation while in reality this does not have any effect on the project itself. We can still continue implementing all the other VLANs. Even the order in which we create the VLANs doesn’t matter. The only thing that matters is the order in which we implement a VLAN. You can’t configure ports with a VLAN if the switch doesn’t have the VLAN so you need to first create it, then put ports into that VLAN. In other words, this would be a parallel project with task groups that are sequential.
Now one could argue that each VLAN could be its own project but that’s not how it matches reality. In this case it is better to keep things together as it gives you a better overview of the overall progress.

I would not use this on simple things like calling someone (I’d just put that in as a single task, might not even file it under a project and/or give it a context *). And that’s the key thing here: not everything is the same and thus we should not treat everything the same. That means that we need to have some flexibility and I feel that having multiple contexts gives us just that.

* Just because you use a system to manage the things you need to do doesn’t mean that you have to put every single item in it. If you’d put everything in OmniFocus you’d be far more busy with entering data than actually getting your tasks done. The latter is the entire point of using tools like OmniFocus. You don’t need to remember every single thing, people know we can’t and are ok if you forget things.

It is not about steps, it is about how long each step can take and not everything is the same. There are large projects and there are small things. What you wrote down is for something really large which requires the CAB (Change Advisory Board; the terminology is from ITIL) to look at it and give the go ahead. It is not going to work with most of the stuff that people from the IT servicedesk encounter (for example: there is a huge difference between an incident and a problem; most companies use something that looks a lot like the incident and problem processes described in ITIL). Lots of these are smaller issues that do not require an OK from the CAB nor that they are informed. That’s due to how things work. You get a lot of things at the same time and sometimes there are emergencies. In reality that means you are doing quite a few things simultaneously and that you may have to put things aside. There are also cases where you simply don’t want to (or can’t) look at it for too long as it makes you go crazy (some things consume energy, some things make the letters on screen dance). What happens is that people will look at it for say an hour and then put it away. They continue the next day or a few days later. If you can divide things into smaller steps and it makes sense to do so then do it, else don’t as it will take away time and energy you could have (and should have) spend at doing your tasks.

I’m also from an engineering background but mine is in IT, especially in system administration (aka building, managing, maintaining and troubleshooting and in my case even some development). These areas differ greatly from IT engineers who program software or engineers who build a stadium (or any other structure for that matter) or any other profession. Like I said before, due to all these differences there is no single solution thus we need flexibility so everybody can create its own. OmniFocus allows this and I think we can enhance it by having multiple contexts. In the end it’s just a tool that supports your todo/time management system. Knowing when to use the tool, what to use it for and so on are all part of that system.


#160

I’m still confused. I think what you are saying is, you want EITHER multiple contexts OR an expansion of the status settings to handle what you want to do. I agree, multiple contexts would handle what you want to do when the status settings on tasks remain as they are.

In my logic, I would have a sequential sub-group set up in a parallel project workflow. The sub-group set would say …

  • discuss VLAN implementations with team (@meeting : team)
  • get final decision on VLAN implementations from team (@waiting on : team)
  • implement VLAN for team (@office)

No toggles needed. The status of any task is either active or complete. We have immediate feedback always on where this portion of the project stands. Enclose it in a parallel workflow and the rest of the project is not held up.

As I understand your logic, you would create this …

  • discuss/decide VLAN implementations with team (@team) – today active, tomorrow on hold, then three days from now active again, then a week later on hold … while we wait for the team to get their act together and toggle back and forth
  • implement VLAN for team (@office)

Truth be told, this workflow idea, if I express it correctly, would be entirely too much work for me to manage efficiently. Too many decisions seem to have to be made when doing the work as opposed to setting up in advance what the project will demand.

The line between adding flexibility as a benefit and adding flexibility to satisfy a desire to have yet another way to do something can be a moving target. I think your proposal to include “on hold” and “waiting on” status states for tasks crosses that moving line the wrong way.

The status of a task is either active, done, or (with a clever hack or the future good graces of Omnigroup) dropped. The rest of the cases can be handled nicely by defer dates, multi-step workflows with “waiting on” steps as demanded, and good attention to efficient layout of parallel versus sequential action groups.

This generalization paints a seemingly rosy picture. I think however it ignores the specifics of why your proposal will increase management overhead in using OF without adding significant, real extra return value.


JJW


#161

What I meant is that for what I want to accomplish there are 2 solutions: a separate status field (could work since we already have some of that in OmniFocus) or something more generic that also caters for other kinds of workflows (=multiple contexts; again, the basics are already in OmniFocus).

That’s the same sort of project that we set up, except that VLANs are the “product” (they are virtual networks) you implement at the customers site. Usually projects like these involve 1 or 2 people at the utmost so no team, especially when it comes to the implementation (if you can’t do it alone then you are most likely not up to the task). “Implementing VLAN” is another subgroup that is sequential but let’s leave that part out as things come too detailed.

And that would be incorrect. We are talking about IT where you need a very high amount of flexibility and improvisation. Usually you do work at the customers site in their already existing infrastructure and a lot of times there isn’t anyone around who has all the documentation and all the knowledge, especially nowadays were IT is done by multiple companies for that same customer. We are also limited by what the hardware plus its firmware can do and when it comes to firmware there are too many pitfalls (and not all of it is documented). Point is that whatever we decided based on all the information that we were given and we managed to get hold of there is a huge change that things need to be changed when you actually start doing the implementation. Sometimes it is also the equipment that is not playing along but we have to get things done so we need to improvise and thus change our plan completely. In some cases this means putting one of the tasks at hand on hold and continue with everything else. The same applies when we do these things remotely. The customer is paying us to deliver and thus we have to.

Btw, in IT clients in IT are devices like computers, tablets, etc. but could also be a piece of software. When we mean the human being version we say customer (the one giving the order/paying for it) or user (the person using it).

Yes, IT requires a lot of improvisation but luckily most things can be done by following normal projectmanagement. The other thing is that we have very small things that simply require a checklist to make sure everything is done correctly up to rather huge projects where we have a projectboard and so on.

For me it is the main reason why I don’t have a very detailed planning/projectmanagement. Mostly the bigger things don’t get changed but the smaller details do. It is also something I learned when doing projectmanagement. You can have too many details making things like planning stuff really really complex.

In your eyes yes but I’ve seen other people think quite differently about that. They don’t want dropped tasks, they want them deleted because they see no reason for such task to remain in their system. Others might disagree because they like having a history of everything (and thus could argue that you never should be able to delete anything). I’ve seen the same discussion with version control systems (especially git because it allows to rewrite history) that developers use. You are either in camp 1 or in camp 2, there simply isn’t anything else. If the status “dropped” should ever be implemented and you are going to use it because you want to have a history then it would a very good thing to specify why you dropped the task (the notes field comes to mind). Only with the last thing you can have a proper history because it is meaningful.

In my case the status of the task is also “on hold” (just like a project) but you can accomplish that with multiple contexts too. The same can be said for the dropped status of a task.

I’m not proposing that. I’m against having all those separate fields as it will greatly reduce usability of the software. A lot of people might use it, a lot of people won’t use it…ever. Contexts are far more suited because they allow everyone to set up their own. I’m only advocating that we need to take that flexibility one step further. In my case contexts would be used for status and some other items. In someone else case it would be used for people. Remember, the software should support whatever system you’ve created and not the other way around. That’s why people tweak and fiddle with things.

The problem you are describing here is something that is already in OmniFocus. Any form of flexibility (like what we have now with the current context system) also introduces complexity. If you look around the forums here you can see many examples of that (many of them are lost in their tooling and are almost obsessed with finetuning it; just take a look at all the context discussions around here). Just knowing how your tooling works and not endlessly trying to tweak it can greatly reduce that complexity.


#162

Let’s take this and run with it. I may be becoming a bit too zealous. I have to be careful to realize that my workflow is not everyone’s workflow.

Well, I must have been totally confused then when you said earlier …

Perhaps what you really were meaning is … “I’d also like to be able to USE MULTIPLE CONTEXTS AS A WAY TO assign a status to an action other than …”

Let’s agree that we both agree that being able to set multiple contexts on tasks would be a good thing.


JJW


#163

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:


#164

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.


#165

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.


#166

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.


#167

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


#168

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


#169

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.


#170

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.


#171

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


#172

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.