[whpalmer4]

I do much like Greg does: I've got an Internet context, with nested contexts for increasingly narrow classifications (primarily which computer, but could also be which network), and a Mac context, again with nested contexts. So, something I can do on any Mac will go in the Mac context. Something I need to do on my iMac would go in Mac : iMac. Something I need to do on my Macbook when it is running Snow Leopard would go in the Mac : Macbook : Snow Leopard context. A task to install a new OmniFocus sneaky peek on my iMac would go in Internet : Mac : iMac. The magic quick match code makes typing these contexts very easy. I can quickly find all the tasks specific to a given computer by drilling down in the hierarchy to the most specific context, and go back up to the more general contexts as the specific ones are completed.

If OF showed the parents as well as the selected context, how would one concentrate on tasks that could be done only in a specific nested context? If I'm looking at Errands : Grocery store, I don't want to see the errands which have no nested context of their own if they aren't actionable at the grocery store. Taking it a step further, I not only have Errands : Grocery store, but Errands : Grocery store : Store #1, Store #2, Store #3 (3 siblings of Errands : Grocery store). Stuff I want or have to buy at a specific store goes in that store's context; stuff that could be gotten at any of them goes in the Errands : Grocery store context. When I'm at Store #1, I'll look at the Store #1 context, buy those items, then look at the parent context to see if any items are on the list that I might get as well. It seems like the "always show parents" approach would guarantee that my view always had a lot of extra stuff present -- it might all be actionable, true, but not productive to have an overwhelming list.

I like to work the most specific contexts first, because I might not be able to in a position to do so later. If, as I move up the hierarchy, some siblings come into view, I group by context and close those groups if seeing the other actions is distracting. Often there are so many actions in the parent that the actions from the unavailable contexts are below the bottom edge and out of sight.

It seems to me that you can simulate the "show parents" approach by selecting the entire context hierarchy, grouping by context and closing off or deselecting the unwanted portions of the tree. Not convenient for long-term use, but I don't think the "show parents" approach would be, either, though YMMV. As I see it, the current approach sometimes gives you unavailable actions in the view, but provides the means to hide them, whereas the proposed approach doesn't give you unavailable actions, but reduces the ability to narrow the focus while potentially showing many more actions. With a small enough crop of actions, that may not be a big issue, but with an action list that calls for an industrial-strength tool like OmniFocus instead of a pretty toy like the competition, why would you want to remove some of the key functionality?