[QUOTE=eurobubba;73848]IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it![/QUOTE]

I feel the same way about groups as you do about projects.

Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?

I know that’s not built in or “hard coded” or whatever, but this sure seems like a lot of complexity and cruft for pretty minimal added efficiency.

[QUOTE=Lucas;73853]Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?

I know that’s not built in or “hard coded” or whatever, but this sure seems like a lot of complexity and cruft for pretty minimal added efficiency.[/QUOTE]

If this were Facebook I'd be clicking the "Like" button.

[QUOTE=eurobubba;73850]At that point, what's the difference between this Review context and the existing Stalled filter/perspective that's already available in 1.7, other than whether it shows up in planning or context mode?[/QUOTE]
I guess the short answer is the place where it's reviewed and actioned. I do most of my work in context mode, switching back to project mode only during planning phases where I need to expound upon a specific project, or during my weekly review.

IMHO, this new behaviour is more useful for Action Groups than Projects, although it works for both. It's easy to pick up on closed/completed/stalled projects in the Planning mode, but action groups can be a lot murkier since they're in-line with everything else.

[QUOTE=eurobubba;73851]Am I understanding this right, that the only purpose of showing parents within context views is to keep them from stalling by alerting the user that a parent's last unfinished action was just finished? If so, why not just alert the user directly by putting up a dialog when the last available action is checked "done" or deleted? That way contexts are kept uncluttered and conceptually clean.[/quote]
IMHO it's a bit more complicated than that. What if I don't want to complete a project, or more importantly an action group, right away simply because the last task is completed? Frankly, if I [i]do[/i], then OF has already had that option for some time in the form of the 'Auto-complete' checkbox for any given Project or Action Group. However, leaving the parent item around in a more appropriate context until the next time it can be "actioned" can be very useful in a number of scenarios.

To put it another way, a dialog box requires an immediate response, which is much different than leaving an action in-place that can be handled at a more appropriate time.

Likewise, often it's important to note that a project is completed and/or awaiting more actions more immediately than simply waiting for the next time you're in planning/review mode.

[QUOTE=Lucas;73853]Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?[/QUOTE]
This is what I've done in the past and it mostly works well enough. However, this new method has a couple of advantages that I can see:

Firstly, it avoids requiring yet-another-task in the project as a placeholder that needs to be managed. This extra task can be very inconvenient if you're regularly updating the project, especially via methods like quick-add or even simply drag-and-dropping items in from the inbox -- they'll end up [i]below[/i] that placeholder task, which you'll then have to repeatedly move downward during your regular reviews to keep it at the bottom, or risk thinking the project is "complete" while there are still other tasks below it.

Secondly, it's even less efficient for somebody who wants to take the approach that the majority of their projects or action groups are actionable and completed separately. A placeholder task works fine as a one-off on occasion, but having to insert them into dozens or even hundreds of projects can quickly get unwieldy compared to simply having the software handle that for you automatically.

[QUOTE=eurobubba;73848]IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it![/QUOTE]

I understand. As you may have noticed, my subsequent posts implicitly revoke that rather radical proposal I made.

I am fully aligned with what Curt suggests (the "bin" idea). I would also be equally happy with Craig's proposal provided that a global "default context" setting for groups/projects is available in the application preferences.

What's really annoying is I thought that we could now actually assign PROPER REAL contexts to projects and groups

I mean, REALLY assign contexts to them, not just set each one a default context for the actions you create in them

I began coming up with all kinds of interesting 'areas of responsibility' type uses for this idea, and other new contexts I could create just for organising my projects

And then I realised it's just a default setting for actions you haven't yet made in the project / group and not project specific contexts at all

Pah.

Actually, "Default Context" is not what's new here -- that's been there for quite some time (1.5? I can't remember exactly when it first showed up). The only difference is the Default Context is [i]also[/i] being used to assign an "active" context to the Projects themselves, so it's serving double-duty, and not in a way that would be practical for many users.

The new 1.8 behaviour does what you're suggesting, it just seems that it uses the wrong field to actually [i]do[/i] it.

[QUOTE=jdh;73862]The new 1.8 behaviour does what you're suggesting, it just seems that it uses the wrong field to actually [i]do[/i] it.[/QUOTE]

I like jdh's proposal. It seems to give the most flexibility without overloading the meaning of the existing default context field.

In projects and groups, maybe the existing field should actually be called something like "Default Child Context" and the new field simply called "Context", just like actions.

A parent's context field could then be displayed in the context column of the main outline. That way you save yourself a trip to the inspector to set it for a group; just tab to the context column and enter a value using smart match. Of course, the Default Child Context field would still only appear in the inspector.

-Dennis

[QUOTE=Toadling;73864]
A parent's context field could then be displayed in the context column of the main outline. That way you save yourself a trip to the inspector to set it for a group; just tab to the context column and enter a value using smart match. Of course, the Default Child Context field would still only appear in the inspector.
[/QUOTE]

It sounds perfectly fine to me but let me repeat what Curt and I have suggested, among others: If this sort of system is implemented, we need a "default" setting for the parents' context field. Many of us will actually create a dedicated context for parents, a context acting as "bin" for parents, so having a global default for that field would ensure that parents would not… well… fall through the cracks!

[QUOTE=macula;73866]If this sort of system is implemented, we need a "default" setting for the parents' context field. Many of us will actually create a dedicated context for parents, a context acting as "bin" for parents, so having a global default for that field would ensure that parents would not… well… fall through the cracks![/QUOTE]

I can live with that suggestion as well. It's more stuff crammed into the prefs interface, but in this case I think it's worth it.

-Dennis