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 > Applying OmniFocus
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
How is next "next action" relevant in a parallel project? Thread Tools Search this Thread Display Modes
OmniFocus wants to have just one next action no matter if the project is parallel or sequential. Won't there be more than one potential next action if the project was parallel?
 
Next action in a parallel project allows you to prioritize tasks based on what you would like to work on next in a project, even though there are no dependencies to force you to complete the top task (next action) in the list first. Sequential projects, as I expect you are aware of, block all subsequent tasks in the list until the next action is completed.

Where this comes into play is how you want to filter, through a perspective or the view bar settings, your action lists. Viewing with a 'Next Action' filter will narrow the choices made available to you as only the top, next action will appear in the list, regardless of the project setting for Parallel or Sequential.

Viewing with an 'Available' filter will give you the next action in a Sequential project and all available actions in a Parallel project. The above assumes that no tasks are blocked by a start date and time. The 'Remaining' filter will show all tasks remaining in a project, even those tasks blocked by a start date and time and tasks blocked in a Sequential project.

While you did not ask about it, the third type of OF 'project' is the Single Action List. All tasks in a SAL will appear in both the 'Next Action' and 'Available' lists as all tasks in a SAL are considered to be completely independent of the other tasks in that SAL.
 
Thanks Greg. That clears it up for me.
 
Quote:
Originally Posted by Greg Jones View Post
Next action in a parallel project allows you to prioritize tasks based on what you would like to work on next in a project, even though there are no dependencies to force you to complete the top task (next action) in the list first.
I would *really* like to have a perspective, with a particular group of projects and SALs that I've focused on, and that shows next actions. To help me focus, and pick off actions that are either truly next (when sequential), or that I've just decided are best to work on. As you've pointed out, one can 'set' (by order listed) a next action in a parallel project. Perfect. But I want to be able to do the same for SALs, using the same philosophy. The only way I can do this is to change a SAL into a project, which I don't want to do.

I seem to recall reasoning from the OmniGroup for having all available SAL actions shown, with a 'next action' filtered applied. It may be useful at times for that to be so, but perhaps a preference to allow the top (list-wise) available action in a SAL (only) to show up with a 'next action' filtered applied. Heck, maybe even a preference to have OF randomly pick what would show up as one's next action, all else being equal. My thinking behind the latter, is that sometimes I'll do a search, and the darndest SAL item shows up that I had forgotten about (I have long lists, mind you). (I've submitted these ideas as OF feedback recently.)

Bob
 
The primary functional distinction between a single action list and a parallel project is that which you propose to eliminate with this option. Why not just change it to be a parallel project? Do you always want to work in this fashion, or only occasionally? If that latter, why not just switch between parallel and SAL as needed?
 
Quote:
Originally Posted by whpalmer4 View Post
The primary functional distinction between a single action list and a parallel project is that which you propose to eliminate with this option.
I'm not sure I understand. My take is that a SAL is a list of thematically-related actions but for which there is never any completion (of the SAL title, e.g., "gardening"), whereas all projects have an ultimate, completable, goal. If that is more-or-less correct, then from a theoretical point of view, all available actions in a parallel project should be (potential) next actions, no? Otherwise, one is prioritizing, which is potentially against the grain of GTDness (yet I realize I'm arguing *for* that kind of thing, so my argument is definitely not backed by pure(?) GTD theory ;).

Quote:
Originally Posted by whpalmer4 View Post
Why not just change it to be a parallel project?
Because SALs have a meaning to me, distinct from projects (in the way I wrote above).

Quote:
Originally Posted by whpalmer4 View Post
Do you always want to work in this fashion, or only occasionally? If that latter, why not just switch between parallel and SAL as needed?
I always want to work in that fashion. I have a large number of SALs, and I don't wish to change them to parallel projects just so that they will yield only one next action.

I do understand that there may be a slight distinction between a parallel project and it's manually-set next action, vs. a SAL and it's potential next action, but for me that distinction falls apart in my practical use. I see the value in manually setting the next action of some parallel projects, and also see no reason why I shouldn't be able to do the same for SALs; I could use that same sense of 'here is what would benefit me to do next in this SAL' by manually setting its next action.

And for those who prefer to see all available SALs as next actions, I'm fine with that, but would prefer an option (via a preference) for SALs to behave like parallel projects in this respect. Thanks for your input.

Bob

Last edited by omnibob; 2010-06-06 at 01:07 PM..
 
Quote:
Originally Posted by omnibob View Post
I'm not sure I understand. My take is that a SAL is a list of thematically-related actions but for which there is never any completion (of the SAL title, e.g., "gardening"), whereas all projects have an ultimate, completable, goal. If that is more-or-less correct, then from a theoretical point of view, all available actions in a parallel project should be (potential) next actions, no? Otherwise, one is prioritizing, which is potentially against the grain of GTDness (yet I realize I'm arguing *for* that kind of thing, so my argument is definitely not backed by pure(?) GTD theory ;).
I agree with the characterization of SAL vs. project, but the software doesn't do much with the distinction (and the theme can be quite legitimately that there is no theme otherwise linking the actions -- the good old Miscellaneous bin which got us the SAL feature in the first place). If you tick the box to complete when all the actions are completed, a SAL will be marked complete just like a project would be with that same box checked. The actions in a SAL are styled differently, and all of the possible next actions are shown instead of just the top one (in other words, Next Action view behaves like Available view for a parallel project).

I don't see anything wrong with the optional notion that the top item on the list is the one you think ought to be done first. If you're doing GTD on paper as described by the book, you certainly have to write something down as the first action on the list!

Quote:
Because SALs have a meaning to me, distinct from projects (in the way I wrote above).
Understood, and I use SALs for areas of responsibility/unending projects as well. But it has little functional bearing on how I use OF, and if parallel projects worked the way I want and SALs didn't, I wouldn't hesitate to switch back to using parallel projects -- probably half of my OF career, I used parallel projects for this purpose. It's pretty obvious which ones are eternal, after all :-)

Quote:
I always want to work in that fashion. I have a large number of SALs, and I don't wish to change them to parallel projects just so that they will yield only one next action.
If you look at it from the standpoint of the team leader deciding how to allocate limited capital for OF changes, does this seem to be a change that users are asking for, that will improve the program for a large subset of the population? Or would the other team members all be saying "uh, why doesn't he just use a parallel project?" It's also one more esoteric option for new users to grapple with (and Omni to document), for little apparent gain in functionality. If you got to pick one feature that Omni would deliver in the next release, would you spend your pick on this? Just to be clear, I have no quarrel with the concept, and if it could be delivered at no opportunity cost, that would be great.

Is this option all or nothing, or on a project-by-project basis, like the project auto-completion?
 
Quote:
Originally Posted by whpalmer4 View Post
Is this option all or nothing, or on a project-by-project basis, like the project auto-completion?
All or nothing.

Your points are well made. I suppose I can add " SAL" to the end of the title of a SAL that I've converted into a parallel project (I already do that for SALs; it is slightly redundant, but works for me in SALs).

I think my main goal is to be able to be able to effectively put attention to (and get done) the mind-numbing long lists that SALs can become. I have had some success with using the next review period to somewhat stagger my SALs so that I can review some of them in depth one week, others on another, etc.

And then for my next-action randomization idea, I could take a whack at AppleScript. Thanks for your useful feedback.

Bob
 
Trying to suss out what might be different between our practices... it occurs to me that almost all of my SAL actions are done either because I work the bin to completion (the grocery list, for example), or they get done because they have a start date and get worked off the daily tickler perspective (household work, paying bills, taking care of the animals, etc.) As long as I'm careful about not having too many things start at the same time (see Curt's prime number review scheduling trick for a great idea here) I don't have to fool around with reordering the lists or even really face them in their entirety. It does help to have a bit of discipline about knocking the items off as soon as they show up on the tickler list.
 
Quote:
Originally Posted by whpalmer4 View Post
Trying to suss out what might be different between our practices...
I get into my system (and out of my head) everything I think I need or might want to do. I have actions that have sat there for years. I've made some progress by moving more into a someday or maybe SAL, which I look at far less often. I realize, even without my OF friend's astounded laughter at my long lists, that I do need to prune more. No technology will help there.

Quote:
Originally Posted by whpalmer4 View Post
... (see Curt's prime number review scheduling trick for a great idea here)
I'll check that out. I've also found this strategy useful for projects: Teresa's Blog: OmniFocus: Changing My Strategy http://bit.ly/aRRGcj

Quote:
Originally Posted by whpalmer4 View Post
It does help to have a bit of discipline about knocking the items off as soon as they show up on the tickler list.
I need more discipline. Thanks for the reminder about that.

Bob
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it possible to have parent action of group in "Project" column? julienl OmniFocus 1 for Mac 3 2012-03-01 01:52 AM
UI prob: app prefs say "autocomplete", project inspector says "don't". Former wins. MichaelJohnston OmniFocus for iPhone 14 2010-03-25 11:49 AM
Can you make an action "parallel" in a project that is serial? tlester OmniFocus 1 for Mac 1 2008-10-13 07:34 AM
canīt assign a project to an action in "context mode" levy OmniFocus 1 for Mac 5 2008-01-07 12:59 PM
Difference between "single actions" and "parallel" projects? jasong OmniFocus 1 for Mac 3 2007-09-08 05:57 AM


All times are GMT -8. The time now is 11:28 PM.


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