I feel the same way about groups as you do about projects.
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!
|
|
FAQ | Members List | Calendar | Today's Posts | Search |
OmniFocus 1.8 sneaky peeks are now available | Thread Tools | Search this Thread | Display Modes |
Member
2010-02-22, 12:19 PM
I feel the same way about groups as you do about projects.
Post 121
|
Member
2010-02-22, 12:21 PM
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.
Post 122
|
Member
2010-02-22, 12:23 PM
Quote:
Post 123
|
Quote:
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:
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:
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.
Post 124
|
Member
2010-02-22, 02:00 PM
Quote:
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..
Post 125
|
Member
2010-02-22, 02:15 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.
Post 126
|
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.
Post 127
|
Member
2010-02-22, 03:28 PM
Quote:
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
Post 128
|
Member
2010-02-22, 03:40 PM
Quote:
Post 129
|
Member
2010-02-22, 03:51 PM
Quote:
-Dennis
Post 130
|
|
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 |