I will respond first to a few points using bullet items.
-
I do not use tool-based contexts anymore, including email, phone, computer, iPad, and whatever equivalent. I have the tools with me or I will find a substitute. So such contexts are of no use to me anymore.
-
When the list was mine and not yours, I would use this statement …
… --> contact Luis to borrow camera (context: do)
I would do so because perhaps I might decide to text Luis or phone Luis or even stop by to visit Luis at his house. I would prefer not to specify that I MUST email Luis. Continuing on this point, when (in the infinite future in a galaxy far far away) OmniGroup ever gets their act together to support multiple tags (contexts), I would file this in a context set (contact + Luis). Unfortunately, the kludges to invoke multiple contexts (with sub-contexts or using note fields or putting special characters in the title fields) are just too time-consuming for me to figure out in a consistent way, so I do not bother. Finally, still on this point, your example and some others that I have been finding on my own got me thinking about an additional problem-solving context called something like “inquire” or “ask about” or “query” in my list. -
I also have location-specific contexts (work, lab, lecture …). So I fully understand the @home when the laptop can only be cleaned there and no where else.
In general, I use the problem-solving contexts in two ways. During the setup of a project, they help remind me that a project must have a start (define, research, propose), a middle (do, tidy up), and an end (deliver/report, close). Certainly, once these contexts are put in practice, the words all mean the same thing … --> do this action. But, during the setup, the distinct wording keeps me honest about why I list certain tasks in certain orders and not some other tasks or some other ordering. This may seem an easy thing in a sequence for selling a computer. Sometimes however, as a project is just being defined, it is not so clear exactly what the specific task is in the list. What is however almost always invariant is that you cannot do something until you have defined what you want to do, and you cannot or should not deliver/report about it until it is done (or nearly so).
The second way I use the problem-solving contexts is also during the implementation of my workflow. Notice in my original context picture here, the sequence of my contexts starts with close at the top and works “backward”. When I pull up my flagged tasks (in a custom Active perspective), the list is sorted by context. This means, every task that I should close shows up on top, followed by every task that I have a deliverable to make, followed by every task that requires me to tidy up … and so forth. That means, I ALWAYS see on top of my list (i.e. as the first action to handle) those tasks that not only are “doable” tasks but also are ones that will close an entire project or action group. IOW, I have a pseudo-priority ranking of my “doable” tasks.
My general reply to your new list with tools is, once you start down the path of using tool-based contexts to a great extent, you have nearly if not completely an entirely different approach to mine. A tool-based approach to contexts pins you to doing tasks based on what tool you have in your hand at the moment. My analogy of this approach taken to an extreme is, it is great when you are someone who likes to hold on to a screwdriver for four hours, tighten all of the screws in the house, and then go find the hammer for the next four hours of work. A problem-solving approach frees you to pick up the specific tool that you need for the next-available task of highest concern at that next given free moment. I have learned that I work better when I recognize that I generally carry my utility belt with me at all times anyway, so I am mostly free to tackle the next important task at hand rather than running back and forth to the toolbox every few hours.
–
JJW
