[whpalmer4]

Originally Posted by macula

Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:

PROJECT MyProject [sequential]
     Group_Task_A [sequential or parallel (doesn't matter)]
           Task_A.1
           Task_A.2
     Task_B

Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.

Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.

That is true only if you aren't including the No Contexts bin in your perspective, or have otherwise narrowed the view to exclude wherever the project would pop up once all the actions are complete. That same issue will be present with the proposal to have a separate bin for projects and groups -- if you aren't looking there, you won't see the project or group becoming available.

The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.

In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.

All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.

You should of course provide your feedback, as you are doing. But I think it is worth contemplating the possibility that with well over 50,000 OmniFocus customers out there, your viewpoint (or mine!) may not be representative of what Ken & Co. are hearing from the customers who are contacting Omni directly for support.

I'm not trying to sell you on this approach being the "right" one. Very little, if any, of this feature comes from suggestions i have made publically or privately, and if Ken decides this afternoon he wants to do something completely different, that would be fine with me, so long as it is an improvement. My aim with my forum posts is to help people effectively use the tools we have, because for the most part, the pace of change is slow, unless they happen to be working on the area in question at the time.