These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

I have a remark about the way nested contexts are viewed in OF. When you select a context it displays the context and all it's child contexts. To me it seems that OF should display the selected context + it's parent contexts instead.

A context list should only display actions that you are able to complete in that context. By including child contexts instead of parent contexts the list often includes actions that you can not complete at that time.

For example consider a context 'laptop' with a child context 'online'. Selecting the laptop context will also give you the online context while in fact you may not be online at that time. A workaround would be reversing the order of these contexts, listing more specific contexts as parent contexts.

The problem becomes more apparent when you have more then one sub-context. For example:

- Laptop
-- Online
-- Office network

If you select the laptop context both sub-context that may not apply are displayed. When you select a sub-context the more general context which does apply is not shown. In this case there are two workarounds:

1. including an exhaustive list of sub-contexts:

- Laptop
-- General
-- Online
-- Office network

2. Fake nesting by using context names:

- Laptop
- Laptop > Online
- Laptop > Office network

The problem with workaround 1 is that you might assign actions to the laptop context by accident. Workaround 2 renders the nesting feature useless.

I think the solution here would be to show the selected context + parents. Is this just me or is there some preference I'm overlooking?

A context list should only display actions that you are able to complete in that context.

I agree with this, but where you and I might differ is how we would set up the context hierarchy to begin with. I want every child level to be a dependent, sub-set of the parent level. What is more important to actually work online-a laptop or an online connection? In my thinking, my laptop is not necessary to go online-I can go online with a desktop, my phone, an iPad, etc. As such, I would (and actually have) a top level context of 'Online' that includes the children 'Email', 'Research', and 'Recreation'. If I can only access the company Intranet while in the office, I'd probably just assign those tasks to the 'Office' context or perhaps have 'Office network' as a child context of 'Office'

This is an interesting idea and I can see how it might be useful. But I wonder if displaying items "bottom-up" instead of "top-down" (i.e. conventional outline/tree-based behavior) might be confusing, especially for new users.

I wish there were some way to try it out. I think that'd give me a better idea of whether it's something I'd like or not.

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?

But I wonder if displaying items "bottom-up" instead of "top-down" might be confusing, especially for new users.

I agree that it might be confusing for a certain group of users. But will it be worth implementing as a preference?

Quote:

Originally Posted by Greg Jones

I want every child level to be a dependent, sub-set of the parent level.

This seems to be the rule of thumb to follow when setting up contexts in the current 'top-down' implementation. But after some experimentation I find it hard to come up with clear and satisfying structure, because:

1. Truly dependable sub-contexts are hard to define
2. You want to break up a context as less as possible

This seems to be the rule of thumb to follow when setting up contexts in the current 'top-down' implementation. But after some experimentation I find it hard to come up with clear and satisfying structure, because:

1. Truly dependable sub-contexts are hard to define
2. You want to break up a context as less as possible

In my experience, contexts (and the few sub-contexts that I have) were easier to define once I realized that they are situational over time. I was an early adopter of the GTD-methodology and popular contexts such as 'Phone' and 'Computer' made sense in the day. Cell phones were not as ubiquitous as they are now, for both the caller and the recipient, high-cost rate plans made us give pause to when and how we would use them, and smart phones were a novelty. Computers were, for the most part, desktop systems or laptops that were more stationary than not as on-the-go wireless access was in its infancy also.

The workplace (for better or worse) has transitioned also. I no longer have a clear delineation of 'Office' and 'Home' any more. Five years ago at my workplace, graduation time meant that my wife and I would put on our robes and go to commencement on campus. Last month my wife 'attended' her online students' commencement ceremony from a smart phone while we were traveling down the Interstate.

In any event, this is a rather long-winded way of explaining that for me, contexts today are more about my mindset than physical resources that are bound by time and/or place. I don't need to think about a phone anymore... or a computer. There are few time/place considerations in my workflow and my old contexts of 'Phone' and 'Computer' have been replaced by 'Calls' and 'Online'. While there are still some time/'place constraints on my workflow that require physical contexts, I avoid creating contexts where physical resources are non-issue.