Quote:
Originally Posted by Magd36
My take on this is that implementing sub-contexts is simply a way of implementing tags through de-normalising the tags into contexts due to only being allowed to attach one context to an action.
|
I don't think I'd agree. In my mind, what differentiates a context hierarchy from a tagging system is the implied relationships between the parent and children.
For example - a big part of my context system involves essentially mirroring Omni's org chart. There's a "Marketing" parent context, for example, with contexts for the folks that work in that department filed underneath. Questions for a specific person go in their context; questions for the entire department (or which anyone in that department can answer) go in the parent one.
I would never file an action in more than one of those contexts, though. There are functional reasons why one place or the other would be the best place to file whatever action I'm considering.
In most of the tagging requests that we've seen over the years, there's often little to no thematic relationship between the ones being requested. You'll see person-related ones, time-related ones, and place- or energy-related ones all attached to the same action and used simultaneously. For every N tags assigned to an action, folks want to see that action simultaneously on N lists, and those lists may 'mean' very different things.
My org chart example isn't the only way to structure a context tree, of course. Some folks structure theirs around the various "headspaces" they need to occupy. Others build theirs around time of day or their energy level. What works best is different from person to person.
Once you figure out which theme works best for you, though, you can build a context tree to support it - and in our experience, once you know what the best theme is, the other stuff is just cluttering up your workflow and distracting you. I think that last part is what's so hard for folks used to tagging systems to understand.
The simplicity of a single-theme approach is actually a
feature; it's not a shortcoming that needs to be addressed or worked around.