Multiple contexts per action?
 

Is it possible to assign multiple (more than 1) context groups for each action in a project?

[url]http://forums.omnigroup.com/showthread.php?t=5718[/url]

The concept of contexts doesn't allow for this - at least in the GTD process. A context is the single place or resource necessary for you to do a task. So, for example, the context for phone calls is my phone. I cannot do those tasks if I don't have that resource.

The idea behind contexts is this: All of our to-do lists are too long for us to effectively sort on the fly constantly. But many of the things on our to-do lists simply can't be done right now because of where we are or what resources we have available. Internet research cannot be done unless I have internet access. Errands cannot be done unless I'm out and about town. Therefore, contexts adds a level of filtering that allows us to instantly rule out every task that we cannot do in the moment because of where we are.

To have multiple contexts would muddy this filtering.

Sure, but there are “sub-contexts”, like sub-folders within the folder, which allow some flexibility. I must say I was concerned at this limitation, and saw it as about the only remaining disadvantage of OF compared with Life Balance, but sub-contexts allayed this a bit. That said, Hermitcrab’s explanation sounds a bit doctrinaire to a non-GTD accolyte. I can think of many situations in which it would help greatly to be able to include tasks in more than one context, on the same principle as smart folders.

Time contexts
 

Multiple contexts would be extremely helpful for dealing with time, for example if you regularly need to phone people in other time zones. The typical context of 'phone' is only partially helpful; best would be a combination like 'phone+atlantic', 'phone+gmt'.

A subcontext (e.g. 'phone:atlantic') is also only a partial solution. You might also need to IM people in other timezones as well, and shouldn't need to enter a duplicate set of time-related subcontexts. I can also think of other time contexts like 'business hours', 'evening', and 'weekend' which I'd like to add as a second context to many of my tasks.

Come to think of it, time context is such an important factor (neglected in GTD?) that it deserves special handling. One's regular timezone could be added as a default time context to every new task, and you could fine-tune as needed (maybe add 'business hours', or 'weekend'). OF could easily make these active/inactive depending on the time of day. When traveling, you could tell OF your current timezone and active time contexts would adjust accordingly. For example, if your regular timezone was Pacific but you're currently in GMT, a task with 'Phone+Pacific+Business Hours' wouldn't be relevant if it's 9am on a Monday, but would be at 11pm on a Friday.

As I think more about this, such functionality would add a level of sophistication to OF that is lacking (as far as I know) in every other GTD app. It would really put it in another category altogether.

[QUOTE=jpl;25709]Multiple contexts would be extremely helpful for dealing with time, for example if you regularly need to phone people in other time zones. The typical context of 'phone' is only partially helpful; best would be a combination like 'phone+atlantic', 'phone+gmt'.

A subcontext (e.g. 'phone:atlantic') is also only a partial solution. You might also need to IM people in other timezones as well, and shouldn't need to enter a duplicate set of time-related subcontexts. I can also think of other time contexts like 'business hours', 'evening', and 'weekend' which I'd like to add as a second context to many of my tasks.[/QUOTE]
Your example appears to be thinking in terms of context1 AND context2, which could be handled using sub-contexts (with appropriate duplication). I could live with repeating some sub-contexts as needed.

However, I wonder if the OP was thinking in terms of context1 OR context2? Here's a perfect example- I need to "Talk to Frank about new contract" which I could do in person (ideal) while in the "Office" or on the "Phone" (if needed). That way, if I'm NOT in the office, but the deadline for talking to Frank is approaching I can see instantly in my Phone context I might need to make that call. And this allows me to rely on the filtering without worry (lose focus) about actions assigned to other contexts that I MIGHT do now.

Now, I don't want a context "Frank" because too many contexts (IMO) is the enemy of good GTD. I can see value in the multiple context approach...

[QUOTE=rh26;25720]Now, I don't want a context "Frank" because too many contexts (IMO) is the enemy of good GTD.[/QUOTE]

I agree that it's generally good practice to have as few contexts as possible, but people are the one exception I make to this rule, for just the reasons you described: the next time I talk with Frank might be in person, or on the phone, or over IM, or in email, and the medium used to communicate isn't actually relevant—what matters is that I'm now talking with Frank, and so I should talk to him about the things that I need to talk with him about.

I don't do this for casual contacts, mind you, but only for people with whom I have some sort of relationship that involves regular contact: co-workers, family, and so on. And I create them all as subcontexts of the context People so that they don't have to clutter up the rest of my context lists.

I make no claims that this approach is right for everyone, but I find it works well for me in my current situation. (It definitely works better than scattering all of my Frank actions across multiple contexts and then somehow trying to find them all without finding everything else I need to say to everyone else once I do get a chance to talk with him.)

IMHO, what we need is a more precise way to characterize contexts which are an intersection of several, well, things (no pun intended): when, whom, where, and how.

We already have the “when”, it’s the start date. The “who” should use the Address Book. The “where” and the “how” are harder to define, especially if you spend most of the time in front of a screen and perhaps can be coalesced in a single entry.

Maybe I’m overengineering this, I don’t know. On the other hand if you read GTD it becomes clear that it’s hard to adapt the contexts system if you use a computer all the day.

Hope this helps

Looking around, it’s interesting to see that the upcoming competition (Things and maybe iGTD2) are using tags rather than contexts. Or, rather, contexts will be just one set of tags. It looks to me that the OF interface is going to be cleaner than that of Things, and the simple Planning/Context Mode-button choice is a case in point, when compared with Things’s potentially endless tag bar along the top. There’s a danger with tags of confusion and overloading. But, and it’s quite a big but, there certainly are circumstances in which multiple contexts or tagging would be very useful, and their lack will be seen as limiting. It’d be a shame if people were put off using OF by the imposition of a narrow way of vizualizing their tasks. It’d be good to see a tad more flexibility here.

[QUOTE=Giorgio Valoti;25740]Maybe I’m overengineering this, I don’t know. On the other hand if you read GTD it becomes clear that it’s hard to adapt the contexts system if you a computer all the day.[/QUOTE]

Or, perhaps, when you're only working on your Mac, it becomes unnecessary. Do you need contexts when you are capable of doing everything anywhere?

A lot of the multiple Context issues can be solved in OF by using nested contexts.

So, you can have the following:

Calls
Work
House Management
Kid-related
Personal

To see all your calls select Calls, to see House and Kids, select both of those contexts.

However, there are a few situations that call for 2 contexts.

One might be if you want to tag actions with both a physical context AND an energy level needed to do them. So you might have Calls / High Energy (asking your ex to remember your kid's birthday this year) and Calls / Brain Dead (activating your new credit card)

You could set up energy levels for every one of your contexts, but that's a lot of hassle — much easier to have an additional context field for this info.

--Liz

Don’t know… You can be right.

However, I still think that the concept of contexts it’s still useful, even when we’re only working on the Mac. It’s just that it’s not easy to come up with a set of useful and clear contexts.

Some actions are tightly bound to a particular program (Mail.app, for example), but I can use Emacs all the day and do wildly different actions, as well. Or I can be on my Mac but I can’t carry out an action because I’m not on site…

I have heard it suggested somewhere else that in some cases, the project could be the context. Meaning that if nearly all your work can be done in one physical context, then contexts might simply be ways to cut up one long action list into shorter, more manageable lists to choose from. In such a case, slecting the project can provide the limits needed to choose what to work on next.

FWIW.

[QUOTE=eronel;26491]I have heard it suggested somewhere else that in some cases, the project could be the context.
FWIW.[/QUOTE]

This is how LifeBalance works. It has a single list of contexts (“places“, as they are called there), but you can include any number of them in any other. Personally I am abandoning LB for OF for any number of reasons, but this - or something like it - is one feature I’m missing a lot.

Btw, for those who haven’t found it, there’s a very active thread specifically on the topic of multiple contexts at [url]http://forums.omnigroup.com/showthread.php?t=5787[/url].

[QUOTE=mcoad;26636]This is how LifeBalance works. It has a single list of contexts (“places“, as they are called there), but you can include any number of them in any other.[/QUOTE]
I liked that about LB too. Very flexible places/contexts.

That's not what I meant in this case though. What I meant is that sometimes if your context list is too long to serve as a good menu to choose from, you break it up into more finely defined contexts. Sometimes you can't, though, and then a good choice can be to just work out of the list of actions for whatever project you want to work on. Hmmmm.... maybe that's obvious, but it's certainly not GTD dogma.

[QUOTE=eronel;26642]I liked that about LB too. Very flexible places/contexts.

That's not what I meant in this case though. What I meant is that sometimes if your context list is too long to serve as a good menu to choose from, you break it up into more finely defined contexts. Sometimes you can't, though, and then a good choice can be to just work out of the list of actions for whatever project you want to work on. Hmmmm.... maybe that's obvious, but it's certainly not GTD dogma.[/QUOTE]

Gotcha. Quite agree. And dogma is there to be defied... The great thing is to work out what’s best for you, and if “good practice” helps then well and good, but if not, roll your own. Seems obvious to me that often there will be projects and contexts with the same name depending on need. Why do people get so hung up about such things? Hey ho... Anyway, all this is why we need multiple contexts, and pronto...