[eurobubba]

Originally Posted by joelande

I don't like that solution - it involves several steps, with a link and creating two tasks for the same thing, one in calls, and one in agenda:

I'm in the pro-multiple-contexts camp too, but until that's available, at least linking exists as an option.

[CareyB]

This seems to be a very odd discussion. Many of the arguments presented here are moot if you define your Contexts more literally. If you try to use OmniFocus like OmniOutliner, you will be constantly frustrated.

Example (and apologies to the poster):

A "Context", in the GTD/OF sense, is a circumstance you find yourself in - holding your iPhone, browsing the Web, in the presence of a specific person, in your office, in the hardware store, etc. Many people seem to try to impose non-contextual organizational concepts on the contextual tools of OF, and find it frustrating <insert favourite DOH!>.

I just saw a blog linked from the previous page of this thread where someone uses a Context of "Agenda", and then sub-contexts from that. Do they actually mean they are in the presence of their agenda? If that's the case, that's fine, but there are a limited number of things one can do in the presence of one's agenda. Then they added a sub-context of Jim (so => Agenda : Jim). Does that mean in the presence of Jim, with their agenda… You see where I'm going with this?

Look around you; search your pockets; look in your bag; sniff the air: That's your current context! If you're thinking about a project such as organizing your agenda, you need to be with whatever tools you use to organize your agenda. If you need to talk to Jim, you need to be in the presence of Jim, or, in the presence of a phone you have access to. Do you have a separate context for each phone? Or a phone context with sub-contexts by location (Phone, Phone : Office, Phone : Home, Phone : Cell)?

It does take a bit of thinking, and working with OF, to get the hang of this reorganization. I find that, if a system has features you use all the time, and you can't duplicate it elsewhere, it's worth learning the system in-depth. OF has the most involved synchronization features (enter data once, and have it appear everywhere), and has good features to thin out your psychic horizon (a big deal for me), like start dates, due dates, calendar synchronization, perspectives, etc.

[dfjdejulio]

Originally Posted by CareyB

A "Context", in the GTD/OF sense, is a circumstance you find yourself in - holding your iPhone, browsing the Web, in the presence of a specific person, in your office, in the hardware store, etc. Many people seem to try to impose non-contextual organizational concepts on the contextual tools of OF, and find it frustrating <insert favourite DOH!>.

So. I've got some tasks that require me to be in the presence of one specific person (my boss), other tasks that require me to be in the presence of another specific person (a documentation person), and other tasks that literally require me to be in the presence of both.

I've got some tasks that require me to be in my office (where certain documents and whiteboards are), other tasks that require me to be in the presence of a specific person (a co-designer), and other tasks that require both.

I've got some tasks that require me to be in the presence of one specific person (a documentation person with expertise on our mail system), other tasks that require me to be in the presence of another specific person (a documentation person with expertise on our data retention policies), and other tasks that require me to be in the presence of any documentation person.

What do I do?

If I can assign multiple contexts to a task via boolean operators ("this AND that", "this OR that"), it's natural. I can note that my context is "in the presence of A, B, and C, at location D, three bars of cell signal, working internet connection", and the system will naturally figure out which tasks I can perform. If I can't, I have to create contrived separate contexts for each combination, and if I'm in the presence of two people and at my office, I won't be shown some tasks that I actually could do. If I can define implicit contexts (eg. "at main office implies working internet connection", "at sattelite office implies working internet connection"), it's even easier.

Alas.

[CareyB]

What you want is a Perspective.

Select multiple Contexts, and save as a Perspective.

[Greg Jones]

A "Context", in the GTD/OF sense, is a circumstance you find yourself in - holding your iPhone, browsing the Web, in the presence of a specific person, in your office, in the hardware store, etc. Many people seem to try to impose non-contextual organizational concepts on the contextual tools of OF, and find it frustrating <insert favourite DOH!>.

I prefer my contexts to be a little less literal as I want to consider other contextual data when deciding on a context to work with at any given time. As example, I always have an iPhone with me, but that does not mean that I am always in a 'phone' context, or an 'online research' context, or an 'email' context. I don't want to make calls when waiting in a doctor's office, but I might want to work with my email. I don't want to email while driving, but I might (and usually I don't) make a call while driving. If I organized my contexts more literally, I would have no need for the above-mentioned contexts just as I would have no need for a context to sniff air.

I just saw a blog linked from the previous page of this thread where someone uses a Context of "Agenda", and then sub-contexts from that. Do they actually mean they are in the presence of their agenda? If that's the case, that's fine, but there are a limited number of things one can do in the presence of one's agenda. Then they added a sub-context of Jim (so => Agenda : Jim). Does that mean in the presence of Jim, with their agenda… You see where I'm going with this

In the GTD sense, this would be a perfectly acceptable example of a context. Allen mentions this specifically, although his example is named Joe instead of Jim! ;)

[CareyB]

Sure… So you have a grip on this, and have your own take on the situation, and that works for you.

However… Perspectives are the answer to multiple contexts.

I really hope you're not referring to OF while you're driving ;-|

[jdh]

To be fair, however, using perspectives and multiple-context viewing doesn't solve the problem of filtering out what you don't want to see, and for some people that can be too much extra clutter to be practical.

That said, while the level of granularity that dfjdejulio describes is a nice idea, it strikes me as antithetical to the "mind like water" approach that GTD is supposed to engender. The convoluted patterns that would be involved in setting up a construct of AND/OR contexts and inclusions seems to create a situation where I'd be spending more time managing my to-do list than actually doing things. Right now I have about a dozen contexts, and it's usually pretty quick for me to figure out where something goes. A labyrinth of interrelated contexts would result in extra mental energy expended to clear out my inbox each morning.

It's a wonderful dream to have a system that is so perfect that you only ever see actions that you can actually deal with. Realistically, however, I don't think any system could ever be that perfect, so IMHO you have to filter as best you can and then live with the rest.

Personally, I simply assign things to their primary actionable context, and if I happen to be missing a resource that I otherwise need for that item, then it's not the end of the world if it remains sitting on the list -- in fact I find that it's useful as a tickler to perhaps go and find the person or item I need to complete the task. To use one of the examples from above:

I've got some tasks that require me to be in my office (where certain documents and whiteboards are), other tasks that require me to be in the presence of a specific person (a co-designer), and other tasks that require both.

In this case, I'd assign those tasks to either be in my office or in a meeting with the co-designer, subject to what the primary scenario for the task is (and what's likely to happen sooner in terms of driving the project forward).

For instance, let's say that I assign the task to the co-designer's name, since I see that person on a regular basis. If I'm meeting with the co-designer outside of my office, the task serves as a reminder to either bring the co-designer into my office (ie, if we're standing in the hallway), or set up an appointment to actually meet with the co-designer at a more appropriate time (you could argue that setting up an appointment might be a separate task, but that strikes me as ridiculously granular for somebody you would see regularly anyway). It strikes me as odd that you would want to completely ignore even mentioning the task to the co-designer unless you're sitting in your office.

Conversely, if the task is assigned to my office, then while I'm sitting in my office, it serves as a reminder to get the co-designer to come to my office to work on the item with me, either immediately or by scheduling a meeting for a later time.

If I don't see the co-designer regularly, then really I should have an precedent task to set up an appointment with the co-designer. That task would be in a context of "Office" or "Computer" or "Calls" (whatever is most appropriate for how you schedule appointments). The following task would simply be tagged with the co-designer's name, since you'd presumably next see them in your office.

The problem I see with using an AND structure is that tasks end up being potentially delayed, lost or missed entirely. You end up forgetting about the task completely until the "perfect scenario" has been formed (in this case, the co-designer just happens to be in your office): "Oh, now that you happen to be sitting in my office, I also have these three things I have to talk to you about, even though I completely forgot about them the last eight times we met up in the hallway.") If your world is predictable and routine enough that you know that the co-designer is going to visit your office regularly for a meeting, then you don't need both contexts anyway (see above). Otherwise, you're setting yourself up for missed/lost tasks by making your criteria too complex.

Note that I'm not arguing against support for multiple contexts, as I can see places where it would be useful at least as an "OR" construct. However, getting into more complicated groupings is potentially fraught with all sorts of confusion and problems, and seems like a situation where people are perhaps relying too much on the software and inadvertently creating complex problems for themselves. Keep in mind that contexts were originally proposed by Allen for a paper-based GTD system, and there are many people out there who are still using notepad and Wiki-style apps to manage their contexts quite successfully. While a paper-based system certainly lends itself to OR contexts (you can write something on more than one page), there's no way you could elegantly handle an AND scenario in such a system.

[pergesu]

I'm not going to read all 11 pages here. It seems pretty obvious to me that if I have a "Call Joe about dinner" in my Phone context, it would be useful to have an easy way to know about all the other things I might want to talk to Joe about. There are tricks for doing it, yes, but I'd rather not resort to tricks. I want to be going through my "Calls" list, and when I find myself on the phone with Joe I want to click on the "Joe" context and see everything else I want to discuss with him. That means putting "Call Joe" in a "Phone" context and a "Joe" context.

[jasong]

No it doesn't. It means calling Joe then tapping through to your Joe context to see other stuff to discuss with him.

You could also have each item named "call joe about ..." if you're only calling him.

[dfjdejulio]

My initial reaction to the "just use perspectives" thing is, that only works if the number of combinations you actually find yourself in is manageable. Like, if on any given day you could be in one of three locations with any subset of six collaborators, you end up with a huge number of perspectives to cover that. (Unless I misunderstood what you're suggesting.)

My second reaction was... "huh, I bet I could whip up a 'dynamic perspective wizard' in AppleScript without much work". Like, if you could categorize your contexts as "locations" (like "main campus" and "downtown campus"), "people" (like "boss" and "sysadmin"), and "assets" (like "projector" or "internet connection"), it might not be hard to whip up a little script that asked you for one location, zero or more people, zero or more assets, and set the filters right.

I will think that over. It still doesn't solve the problem of actually needing different sets of contexts for different tasks, and I'm not quite happy with the "oh, just pick one" answer.

A way to set up "implied contexts" would still be fabulous. From a design point of view I'm thinking about stuff like the way Debian package dependencies work: saying "when I indicate this context, that means this set of requirements is met", and then making things depend on the derived values. So like, I know that both our main and downtown campuses have access to our private network, every time. I know that our "email documentation specialist" is also a "documentation person". So how do I specify a requirement as "I need a documentation person" when I enter a task, and specify my current context as "Joe is in the room with me right now" when I'm looking for tasks?

(Which could actually be a pretty nifty feature for the iPhone client -- use Bonjour to detect other OmniFocus users locally, so if I am a "context" for them, their copy of OmniFocus figures out that I'm available, and vice versa. Hm.)

Can you "fake it" with perspectives? Maybe, but it would get pretty hard to manage pretty quickly... without some sort of 'wizard' to construct them sensibly... which again maybe we can build with AppleScript. I haven't checked, can I bind arbitrary metadata (that OmniFocus itself ignores) to a context? I know the iPhone client can glue GPS coordinates to a context, and the desktop client will ignore 'em (and that's damned nifty). Can we add our own "fields" for that kind of thing, so that we can write our own scripts to build context-sets derived from metadata rather than by manually constructing them? Like, can I create a context of "Mary" and glue "documentation person" and "staff council rep" to that context as metadata that my own scripts can then use?

The "stuff will get lost" argument is not one I find compelling. That's the case even with well-defined single contexts, if you don't visit a context often enough. In order to prevent that even with single contexts, once in a while you have to sweep through all your tasks regardless of context. I'm doing that already. The same solution would do just fine for things that required multiple contexts.