TOPIC: Associate more than one context to a single action

Using 'topics' to include locations or creating context combinations is a good idea but I still think an independent 'location' category would make sense.

The way I use topics is as a classification of project types. So I have topics like 'research', 'home repair', 'shopping', 'teaching', 'administration', 'social obligations', etc. This allows me to review projects by category in a very easy way. Introducing locations as topics for me would complicate things and make them less intuitive since the two categories or of a rather different nature.

One of the beauties of ThinkingRock is its powerful filtering and sorting system. I think the filtering system could be taken advantage of much better with an independent 'location' category rather than with contexts which are combinations of more than one context or with a topic category that encompasses "real" topics and locations.

For instance, suppose I want to see the list of actions I can do at location X ('my office', 'home', 'the train'...). If I have an independent category 'location' and I apply the filter in the actions view, this will yield a list of all the tasks that I have to do in that location. This will include more general contexts such as 'computer' or 'telephone' but also tasks that have no particular context (because they involve talking with X and Y, for instance). Creating different contexts such as 'computer@X', 'phone@X' and '@Xlocation' and then searching for these 3 contexts adds more complication to the whole process.

Or I might want to review the category 'shopping' (because I want to do some planning) independently of where the shopping happens. If I apply the right filter in the actions view, I get a list of tasks that have to do with shopping. Then I can sort the items according to location (if such category existed). Say I have an action categorized as 'shopping' which is something like "Ask X for advice on the best store to buy green tea". This would appear in the list I have obtained by choosing the topic 'shopping' but it would not appear if I have topics for different locations. Having created a context such as 'shopping@MallX' would not have given me the desired result either.

I don't know. Don't you think that adding 'location' as an independent category would make the system more intuitive and useful? Adding this category doesn't seem to be really complicated from a development perspective and it wouldn't add to the overall complexity of the system. People that have no use for it can simply ignore it. Furthermore, you could gain in general flexibility to find workarounds for complex situations that require combinations of categories even if those categories are not real locations. For instance, having location as an independent category would allow for the association of more than one context to a single task by using the category 'location' to incorporate contexts that are actually not real physical locations.

In David Allen's "Getting Things Done", he writes about contexts:Although contexts are clearly relevant to locations in a topographic sense, it would appear more important that contexts should be applicable in a "specific location" where the means to do a Next Action are available. This would lead me to think of contexts as being mutually exclusive, although I'm willing to accept that there may be exceptions to such a rule.

Hi,

Your point is well taken and in essence I agree with you but I think the view you take of contexts might be a little too limiting. In the GTD book, the author can only talk about concepts in a very abstract and general sense but in reality the notions of context that might be meaningful and relevant for each person differ considerably.

Contexts can be complex ones and a good tool must be able to handle this complexity in the most elegant way possible. One shouldn't be fixated with the label 'location'. You can call it 'specific context' (as opposed to 'general context' ) if you want. The name doesn't really matter. The point is that by being limited to a single context for each action, you are forced to look for workarounds that in fact make the system more complex and less usable.

I think there have been a few examples in this thread where people need to use "complex contexts". Claire's was a good example: she has 5 different contexts for 5 different shopping areas. That is her "shopping reality" in Wellington. That is obviously what she finds more useful instead of having a single general context related to 'shopping'. For my life in Barcelona, perhaps with 4 different shopping contexts I might have enough but other people with different lives in different cities might find it useful to have many more shopping contexts.

Here's another scenario that is not so far fetched. There is some shopping that Claire, me or whoever can do in any of the shopping-contexts we have created. You would need then yet another context for general shopping that is not tied to any of the other specific shopping contexts. Otherwise when you are at this context where you can do any of the shopping that you could do in the other 5 shopping contexts, you would have to look into 5 different contexts to see if any of the actions that you have planned in them can also be taken in this particular shopping context. If you don't want to create a general 'shopping' context, you then have to create an identical shopping task repeated 5 times for each of the different shopping contexts you have.

If in addition to shopping you have other types of contexts that can also involve some complexity and where you would need to create more restricted contexts besides a more general context label (say 'computer at location X' in addition to 'computer' ), then the list of contexts can become very unmanageable. I could go on and on providing realistic examples where not having more a more flexible system of contexts can make things complicated.

I think that what is more essential in the GTD philosophy is the idea of having a trusted system that can help you identify the actions that are relevant for each particular context rather than being very picky about what constitutes a context and what constitutes a location.

Having an additional category like location would in fact simplify the system and make it more GTD friendly. You wouldn't need to worry about having many labels for contexts that are combinations of other context labels. You would be able to have simple labels like the ones that are typically mentioned in the GTD literature: computer, telephone, shopping, errands ... Only if needed, you could add an additional label to make this context more specific.

For instance, if I'm at a context where I can do any kind of shopping, I just look for the tasks associated to the context label 'shopping'. If I'm at a specific shopping area where I can do only a limited set of shopping tasks, I just look for the items associated to that specific location label (if that specific location happens to be connected to shopping activities, as in the case of Claire's examples) or I look for the items associated to the shopping contexts that are also associated to this particular location (if that particular location tag is associated also to other actions that are not necessarily shopping actions). Same with 'computer', 'phone', 'errands', etc.

Think about the usefulness this system might have when it comes to doing reviewing or generating reports in conjunction with the TR filtering system.

jfontana wrote:
In my experience talking to people who have had this or similar issues, the solution has almost always been knowing how to use good custom action screens and having a good context list.

For example your shopping dilemma. If you have things you can only get at a ShoppingLocationX, then by all means have a context for that. Something you can get anywhere then goes in @Shopping. And then you have an action screen for Shopping which includes all of the shopping-related contexts and you can then sort or filter, but it's all in one place.

Multiple contexts is usually not the answer. As per previous conversations an alternate technological solution would be hierarchical contexts, so that by choosing ShoppingLocationX it is automatically included in the parent context, Shopping. That is no small feature to add, and can complicate things, so be careful what you wish for.

purpleflux wrote:
Imo, a hierarchical structure for contexts would not necessarily solve the problem. Think of the following contexts: "computer", "at home", "at work", "computer at home", "computer at work". Those are quite realistic cases:

• computer might be anything to surf the web
• for computer at home, imagine something, that you wanna do with your special app, that you only got at home
• for computer at work, take some corporate e-mail for which you need access to some files, that you can only get from your workplace's server
• for at home, imagine taking out the garbage
• for at work, i have right now something, that i'm waiting for someone to give me feedback. This might be e-mail, walk by, or meeting him at the coffee machine, so it's not computer at work

in this case, your context would be hierarchical: at work -> computer at work; computer -> computer at work/computer at home; at home -> computer at home.

So you can basically have again combinations of contexts. (That said, i usually manage with maybe 10 contexts, quite well.)

As for me, the feature of hierarchical context would be nice, sure, but it is not that hot for me. If you actually want to make a general shopping and a very specific shopping, then I'd suggest the use of "normal" contexts and simply choosing multiple in the filter view.

I agree with Icey: a hierarchical structure for contexts doesn't make much sense to solve the problems I was mentioning. It would be harder to implement than just adding a new category related to contexts and would have very little usefulness IMO.

I think what one (meaning above all the developers) should ask oneself is what would be the cost of building an additional context category called Location (or whatever) in relation to the advantages.

I believe (until I'm proven wrong) that incorporating the new category could be implemented rather easily and could be a great boon for many users, who could use it rather creatively. As I said in my initial message, nobody forces anybody to use it. It can easily be left unused as with other categories in ThinkingRock without much complication.

If for some users a single context category with 15 different contexts works fine, more power to them. I'm sure for some other users, though, having the possibility of combining contexts (or location and context) might be very handy and open up the door to some other interesting possibilities. I've been using context and location in Remember The Milk for quite a while and find it extremely useful.