[Brian]

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.

[Magd36]

Originally Posted by Brian

....I would never file an action in more than one of those contexts, though.....

I wasn’t really thinking of the “assigning multiple contexts to an action” point of view.

However sticking with this for a minute, and if we look at the hierarchy proposed, let’s consider if Joe is in Sales. I can’t help thinking that when the context Joe is assigned to an action it is inherently assigning 2 contexts to the action i.e. Sales and Joe (otherwise why have Joe as a sub-context of Sales).

Is the weakness of this not that when you unexpectedly meet Joe and quickly bring up his context you may fail to ask him the general Sales questions that he could have answered?

[Magd36]

Originally Posted by Brian

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....

Where my thoughts were coming from was more to do with inefficiency in a context/sub-context structure. If we consider the scenario where Joe works part-time in Sales and part-time in Accounts, to represent this we would need 4 contexts i.e. Sales, Accounts, Joe under Sales, Joe under Accounts. With tags we’d only need 3 i.e. Sales, Accounts and Joe. While this increase is trivial in a simple structure I’d imagine it becomes quiet wasteful as the number of contexts increase.

However, from all the suggestions, I think I’m concluding that the key seems to be:

1. Use verbs in the action rather than assign contexts.
2. Keep contexts to a minimum and set it around a theme where possible. (I simply hadn’t thought of it like this before).

Following this advice I think I can get my Personal contexts to as few as 4 and my Office contexts to 3 with 4 sub contexts.

I’ll post what I’ve ended up with for constructive criticism later!!!

Thanks for all the ideas.

[whpalmer4]

There's no appreciable cost to having additional contexts, within reason. I would argue it is better to have "too many" rather than "too few" as "too few" results in seeing tasks displayed which you cannot actually do. If you just have a Sales context and are forced to throw tasks which can only be done with Joe into that context, every time you pull up the Sales context and Joe isn't present, you see all of the tasks which require Joe cluttering up your view. Looking at a hierarchy of contexts, grouped by context, you don't see anything for contexts which have no actions.

If you have difficulty with having a Joe context at several points in the context hierarchy, make a perspective to collate them all together.

Rule of thumb: if OmniFocus is frequently showing you tasks which you cannot do, you've either assigned the tasks to the wrong contexts, your context structure needs refactoring to capture the distinction between the tasks you can and cannot do, or both.

[GeoffAirey]

Originally Posted by whpalmer4

If you have difficulty with having a Joe context at several points in the context hierarchy, make a perspective to collate them all together.

Rule of thumb: if OmniFocus is frequently showing you tasks which you cannot do, you've either assigned the tasks to the wrong contexts, your context structure needs refactoring to capture the distinction between the tasks you can and cannot do, or both.

You're assuming that everyone uses the Mac App, but I very rarely get into it due to location and having to use Windows at work.

To be honest, my problem is the other way around. I'm not seeing things I need to do because there's no way to assign Actions to multiple contexts where thins can be done and I can't see a way to do this without multiple tags.

You seem to see multiple tags as having only having an OR relationship, which is one use, e.g. Fred, or Rose or John, but it can also have an AND relationship. Phone AND Alert AND Laptop AND Fred. Yes that can be done as project but that seems pretty inflexible. What if you have all there, or 3 of the 4 which you can quickly rope the 4th into.

Different people work different ways.

[whpalmer4]

Originally Posted by GeoffAirey

You're assuming that everyone uses the Mac App, but I very rarely get into it due to location and having to use Windows at work.

No assumption made. I do this all the time on the iPad. Yes, it is necessary to have the Mac app to make the perspective, but that's a one-time operation. You could even get the Omni support ninjas to build a perspective for you if you don't have the Mac app.

If you choose to work in a way that makes it impossible to do what you want, that's your choice.

I didn't respond earlier to your prior post, but I see nothing in the list of "new situations not present 12 years ago" that hasn't been true for much longer than 12 years. Reporting to more than one boss a novel concept? Hardly — see for example Galbraith, J.R. (1971). "Matrix Organization Designs: How to combine functional and project forms". In: Business Horizons, February, 1971, 29-40.

[Magd36]

Originally Posted by whpalmer4

...You could even get the Omni support ninjas to build a perspective for you if you don't have the Mac app...

Now that's interesting as I don't have a MAC so could be useful for me. I think it would fix my point when I posted:

"Is the weakness of this not that when you unexpectedly meet Joe and quickly bring up his context you may fail to ask him the general Sales questions that he could have answered?"

If perspectives group contexts is this kind of like making contexts act like tags?

In general, my office contexts seem to operate around "time required to complete" as I usually have everything I need, where as my personal contexts operate on a "things I need to complete" basis.

[eurobubba]

Originally Posted by Brian

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.

[...]

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.

One thing I think you're missing here is that there are many reasons to want to view a filtered list of tasks other than being ready to work on them. Off the top of my head, I might need to review tasks from different contexts and projects for the same client or with input from the same vendor/subcontractor, or billable versus non-billable.