Multiple Contexts per Task [now in TestFlight]

The definitive statement of intent and the proposed time-line given in this last paragraph are much appreciated.


JJW

3 Likes

I came over from 2Do because they could not really get the syncing to be reliable, I really like their user interface. The tool always seems to be right there and you manipulate the task my dragging and dropping vs OmniFocus’s typing information. Switching from 2Do to OmniFocus felt like going from a MAC App to a IBM Mainframe app. I liked the ability to Tag and found it rally helpful.

4 Likes

What were you using for 2Do’s syncing? CalDAV or Dropbox? Tried the latest (3.5 and 2.0) versions?

rotfl…nice going, @SteveU… iCloud sync is now superrobust and fast for me for three months… Can’t complain ;-)

I sometimes look back and question my decision to move to OmniFocus, but so many people love it that I feel I just need to work it until I get it.

The folks on the OmniFocus support line are great. 2Do’s support was non existent.

I moved a post to a new topic: Can we have the ability to control the size of the windows?

I moved a post to an existing topic: Are custom fonts/colors/styling in the outline view supported?

I would like this as well. I see this topic has devolved into a whole huge discussion of what “should” be implemented, but I’d like advice on this real-world example:

I need to buy light bulbs. I have a context for “hardware store”, one for “discount store” and one for “IKEA” I can buy light bulbs at any of these places. Why can’t I assign all three contexts for “buy light bulbs” so that when I arrive at IKEA or the hardware store in my neighborhood and pull up the appropriate context, “buy light bulbs” is there?

Can someone tell me why that violates some sacred tenet of GTD?

There is no secret tenet. Multiple contexts - or something similar - is coming. See the post above from Ken Case @kcase.

1 Like

Ah, thanks – I missed that in this lengthy thread.

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.

5 Likes

Great tip, thanks much!

1 Like

any news, about multiple context?

TIA

amelchi

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

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.

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

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.

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

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.

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