The Omni Group
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!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
OmniFocus 1.8 sneaky peeks are now available Thread Tools Search this Thread Display Modes
Quote:
Originally Posted by eurobubba View Post
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!
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 really easier 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:
Originally Posted by Lucas View Post
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 really easier 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.
If this were Facebook I'd be clicking the "Like" button.
 
Quote:
Originally Posted by eurobubba View Post
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?
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:
Originally Posted by eurobubba View Post
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.
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 do, 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:
Originally Posted by Lucas View Post
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 really easier than just adding an action to the end of groups that you so choose to review them and make sure they’re done?
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 below 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:
Originally Posted by eurobubba View Post
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!
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.

Last edited by macula; 2010-02-22 at 02:02 PM..
 
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 also 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 do it.
 
Quote:
Originally Posted by jdh View Post
The new 1.8 behaviour does what you're suggesting, it just seems that it uses the wrong field to actually do it.
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:
Originally Posted by Toadling View Post
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.
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:
Originally Posted by macula View Post
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!
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
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
OmniFocus 1.7.5 sneaky peeks underway! Ken Case OmniFocus 1 for Mac 1 2009-10-21 01:34 PM
OmniFocus 1.7 sneaky peeks have begun! Ken Case OmniFocus 1 for Mac 56 2009-08-27 04:37 PM
OmniFocus v1.6 sneaky peeks! Ken Case OmniFocus 1 for Mac 32 2009-02-26 01:12 AM
Sneaky Peeks gone? Smithcraft OmniWeb General 5 2007-10-25 05:10 AM
CPU use in sneaky peeks hardcoreUFO OmniWeb Bug Reports 7 2007-08-31 02:23 PM


All times are GMT -8. The time now is 02:17 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.