wdiadamo, what you're describing sounds similar to what the head of our UX team was describing when he wrote his Slay the Leviathan Context post on our blog. Almost all of his work requires a computer and/or 'net connection.
It's similar to the approach that Sven describes in his post, but a different set of cuts across the task database. Our CEO uses a similar approach to separate out his CEO-tasks from his engineering-tasks.
What Arrow originally proposed in this thread wasn't a "persuade everybody to use contexts" thread, so I won't go too far down that road except to say that a more open definition of contexts as "useful categories of actions that cut across my various projects" may be helpful. While the roots of the concept were tool-based, there are a lot of ways you can use them.
Maybe it's because contexts-as-they-are work really well for me, but I have a hard time imagining a workflow where some set of contexts wouldn't be helpful. Garyo's approach, for example, would be a set of four contexts.
It's similar to the approach that Sven describes in his post, but a different set of cuts across the task database. Our CEO uses a similar approach to separate out his CEO-tasks from his engineering-tasks.
What Arrow originally proposed in this thread wasn't a "persuade everybody to use contexts" thread, so I won't go too far down that road except to say that a more open definition of contexts as "useful categories of actions that cut across my various projects" may be helpful. While the roots of the concept were tool-based, there are a lot of ways you can use them.
Maybe it's because contexts-as-they-are work really well for me, but I have a hard time imagining a workflow where some set of contexts wouldn't be helpful. Garyo's approach, for example, would be a set of four contexts.
Threaded Mode