Here’s a typical example. Take a set of actions related to a person you interact with. Say his name is “Jarrod”. Some actions might best be completed by meeting with this person, some by email, and some by telephone. So if you want to follow the GTD methodology correctly the actions should be broken into three contexts, which might look like this
@Jarrod
@Email
-@Jarrod-Email
@Phone
-@Jarrod-Phone
This is what I’ve done in my system. I’ve made the contexts for the email and phone actions as sub-contexts in order to separate them from the other actions, making them easier to filter out.
However, the email and phone contexts most likely could also be completed when meeting with Jarrod in person. So I would want to view all three of these contexts together when meeting with him. The only ways I know of to do this are:
Focussing on all three contexts, which isn’t possible in the iOS version (AFAIK) which is typically what I would want to use when meeting with a person
Do a key word search, which can bring up irrelevant actions
Make a custom perspective, which means I need many custom perspectives if I am interacting with many people.
All three have drawbacks, as I’ve noted. So, it seems there is no elegant way to do this.
I believe the correct solution is multiple contexts, which of course is not possible either.
I think if you have a person as a context, they should be the context. Separating it to three separate contexts for one person is too much detail in the contexts. I would just have @Jarrod as a context.
My approach is to use search filters to build a perspective. I have a standard where any task requiring someone else is formatted like this:
<name> - <task>
So a task might be:
Tom - describe the requirements for the new project
I would then assign that task a context that describes where/home the work takes place. Contexts might be:
Email
Call
People/Agendas
Waiting
Then, lastly, I would have a perspective that doesn’t use project hierarchy, sorted and grouped by context, showing remaining tasks with a search filter on “Tom -”. In this way, I see all tasks relating to Tom, but still grouped by the relevant contexts.
I hope this makes sense. I’m not sure if it exactly helps, but I have found this to be useful.
Are you saying, in your system if you have an action to phone somebody that you already have a context for (@Jarrod), you put that action under that context, not under the context for telephone calls (@Phone)?
Yes, I think I got what you are saying.
It seems to be in line with the GTD methodology in that you are putting the actions under the context where it can be completed.
It’s also a bit simpler than my idea of using a separate sub-context for each person.
I’ll keep your approach in mind.
I use two different approaches. One is for actions I must do to reach someone. I have a context called “☎️ contact”. I set the task by method and name, for example
email John about dinner
call Sue about party
message wife about travel plans
This context is a sub-level in my “do anywhere” top-level set.
🎯
✅ close
…
☎️ contact
The second approach is for actions that are delegated to someone. I have a top-level context called “📫”. Under this, I have a first level for “Work” or “Personal”. Under each I these, I have the people or groups who fit, for example.
📫
Work
👥 Colleague
…
💈 Vendor
Personal
👨👩👧 Family
…
🏪 Store
I have a perspective called “Waiting On” that shows only this set.
The approach presented by @deturbulence is an interesting one in that it uses “tools” for the first two contexts. I’ve used such an approach in the past but since prefer to put the method as the action verb in the task itself.
@DrJJWMac Yes, those are my few contexts that limit by tool - most of my contexts are about frame of mind. Indeed all of the examples I used are actually subcontexts of a larger context called “Communicate”.
@nielkfj GTD methodology doesn’t prescribe how you approach this. All GTD says is that you capture what’s important, clarify its meaning and outcome, organize it in a way that makes sense sense, review regularly, and then engage accordingly based on limiting factors. There are many fine ways to skin this cat :)
One other note. The use of a new database format for OF sets the foundation for tags (multiple contexts). Your question would have a different answer once that happens.
I was trying to organize actions strictly according to the physical thing (tool, location, person etc.) needed to complete the action. Those physical things would be the contexts.
But this seems to be too complicated because for actions involving communication with a person, for example, the actions might be divided into different contexts (the person himself/herslef, email device, telephone etc).
Furthermore, for communication with a person, probably all the actions should all be in one context anyway since they should be discussed with that person at the same time, not some actions in person at one time, some actions by email at another time, then some action at yet another time by telephone. I guess that is why David Allen made the “Agendas” context in his book.
I see, you have combined actions requiring different communication methods (email, telephone, text message) into a single context “contact”. And you have divided all the “Waiting On” actions into groups according to who it is delegated to.
In my system I was trying to organize actions into contexts strictly according to the physical thing (tool, location, person etc.) needed to complete the action. But I’m thinking it is too rigid now, because actions with respect to one person might then be divided into different contexts according to the tool used or location.
Also, right now as I am setting my system up, I’m not planning to separate delegated actions into a separate context. I’m planning to keep them in the same contexts as other actions. I’m not sure how this will work out, as the delegated actions might start to cloud the picture to the point where I can’t easily see the actions that I need to do. I guess I’ll find out.
I’m not committed to following the GTD methodology strictly. (In fact as I’ve been setting my system up I have already made a few changes.) But I don’t want to deviate too much. I want to see how well it works, understand it, then make changes if I think I can make my system more efficient.
Contexts are really the same thing as tags, as far as I can tell. Even the project assignment is just another type of tag.
Frankly, I think David Allen invented the GTD methodology based on a paper system, where it would be impractical to sort actions into more than one context. But a computer can sort actions into as many contexts as you want effortlessly. So I think OmniGroup has basically written the software according to the rules of a paper based system (with respect to contexts), and in doing this has unnecessarily limited the software.
I couldn’t agree more. Contexts are an outdated concept, presently useful mostly for location and certain tools. Tags will be more useful, especially for GTD agendas, mostly people or departments. Hopefully getting closer with new OF file format. Meantime, I manually tag tasks that need it (not every task) with @tag, at the start of the task. Makes for easy search too. Downside is having to manually type each time and chance of inconsistency (Was that tag @JS or @Joe or @JoeSmith?). Using context trees and perspectives is extremely cumbersome for this particular purpose.
Examples:
@Joe@Zucker@admin Discuss changes to project deadline
@Recordsdept (can be anyone in dept) Retrieve invoice from client X
