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

 
RFC: Revised definition of "next" action. Thread Tools Search this Thread Display Modes
Quote:
Originally Posted by pjc View Post
"Next" would use the algorithm I suggested (which mirrors GTD's use of "Next" more closely).
I don't want to start a holy war, so this will be my last comment on this topic. That said, I think the current implementation does reflect GTD's notion of a next action.

The basic planning tools in GTD are (1) a list of actions by context and (2) a list of projects (open loops that can't be done in one physical action). For each project, one should identify the single physical action ("next action") to move that project forward and put it on the appropriate context list.

That's what the OmniFocus "next" filter identifies.

Now, OmniFocus allows us to go further by defining some projects as parallel and letting us brainstorm other actions that we'll need to do. Since those actions are, in principle, available to be done, they can be included on context lists of actions that can be done. That does not change the fact that we should have identified one action as the next one to be done to move toward closing the loop.

Though David Allen doesn't say so in his book, it seems to me that the idea behind this single next action approach is to ensure that, as we do things, we make progress on all our open loops, rather than getting bogged down by obsessively planning a handful of them. The idea that next actions are equal to the first available action in a given context will lead users to do more on the projects that have been meticulously planned, not to give equal attention (given constraints of context, time, energy, and priority) to all projects.

That's my brief for retaining the current behavior. As I said, it will be my last word on the subject. I hope it gives a good sense of why I think this proposal would be counterproductive. I realize others, with different workflows, might disagree. But it seems simply wrong to claim that the current OF implementation is anti-GTD.
 
Quote:
Originally Posted by brianogilvie View Post
I think the current implementation does reflect GTD's notion of a next action.
...
For each project, one should identify the single physical action ("next action") to move that project forward and put it on the appropriate context list.
...
[W]e should have identified one action as the next one to be done to move toward closing the loop.
Brian -- I agree with you. I think the current implementation is GTD.
 
Although (repeated for the 6th/7th time in this thread) nobody is disagreeing that the utility of the current Next option is useful, it's not "next" by any definition I'm aware of in English (though frankly GTD, especially the book, is excessively broad in its definition of a Next Action list, doesn't nitpick, and probably doesn't care).

Having an empty Next list for an accessible (focused) context despite having next actions to do is counterintuitive, and this happens often in the current functionality. To use Ethan verbiage, it does not "shrink to fit."
 
Quote:
Originally Posted by djbell View Post
Although (repeated for the 6th/7th time in this thread) nobody is disagreeing that the utility of the current Next option is useful, it's not "next" by any definition I'm aware of in English (though frankly GTD, especially the book, is excessively broad in its definition of a Next Action list, doesn't nitpick, and probably doesn't care).

Having an empty Next list for an accessible (focused) context despite having next actions to do is counterintuitive, and this happens often in the current functionality. To use Ethan verbiage, it does not "shrink to fit."
I think "next action" as implemented by OF is the correct use of the phrase in GTD. "Next action" is an attribute of a project, not a context. While there may be other available actions in a parallel project, there is, IMHO, only one "next action" - the one I choose to be next for whatever reason makes sense to me in the moment.

What was originally proposed was redefining the term "next action" to mean the "first available task in each project within the set of currently selected contexts." A list of "first available actions" may be a handy feature to have, but I don't think it is a list of "next actions," as the term is used in GTD.

What I disagree with is redefining "next action," not with including the ability to filter for "first available action" within a context.
 
Maybe we should just name things in OF in ways they might make sense in plain English. Like GTD's definitions.

Quote:
Originally Posted by David Allen
After checking your calendar, you'll most often turn to your "Next Actions" lists. These hold the inventory of predefined actions that you can take if you have any discretionary time during the day. If you've organized them by context ("At Home," "At Computer," "In meeting with George"), they'll come into play only when those contexts are available. "Projects," "Waiting For," and "Someday/Maybe" lists need to be reviewed only as often as you think they have to be in order to stop you from wondering about them.
 
Quote:
Originally Posted by brianogilvie View Post
I don't want to start a holy war, so this will be my last comment on this topic. That said, I think the current implementation does reflect GTD's notion of a next action.
As the instigator of this current debate, I have to admit that you have explained your view very well, and I find your perspective on "Next" actions enlightening. I really like your point people potentially not balancing their projects.

However:

Quote:
Now, OmniFocus allows us to go further by defining some projects as parallel...
And it is in OF's application of "next" to this extension of GTD that I feel the current notion of "next" isn't quite following GTD's spirit.

In the case of sequential projects, my generalized notion of "next" reduces precisely to your notion of "next". If one prefers to adhere strictly to GTD and use only sequential projects, either definition of "next" is equivalent.

However, if you accept the notion of parallel projects, then it seems to me that the definition of "next" should not be so rigidly sequential. Instead, I read the spirit of "next" mean "the next action in a project that I can do in my current context(s)":
Quote:
Originally Posted by David Allen
These hold the inventory of predefined actions that you can take...
(emphasis added, thanks djbell for the quote)

Again, applied to sequential projects, this reduces to precisely the traditional definition of "next", because only the top task in a sequential project is available. But applied to parallel projects, it means I can see one task (the "next" one) per project in my current context(s).

To your point, this could indeed cause people to lose some focus in their parallel projects -- but I would suggest that this is the essential result of making a project parallel. To retain the focus you describe, the project ought to be sequential.

That's the theory, anyway. In practice, I have to think about whether certain projects are making less headway than they could simply because the "next" filter is too restrictive. Yes, I can switch to "Available", but that list is far too long and overwhelming, and breaks the "Mind Like Water" state. Switching filters in this way is effectively a form of planning, which really shouldn't be so pressing. I've scheduled a review for each project, and I don't like having to review projects more often than that just to see whether I need to reprioritize (simply to tweak the "next" action) because of a varying mix of contexts day to day.

In short, "next" is too narrow for parallel projects, and "available" is too broad, at least for me.

p.s. Please don't remain silent out of fear of a "war" -- this is an RFC, after all! I specifically want to hear a variety of viewpoints, especially if they differ from my own!

Last edited by pjc; 2007-09-14 at 07:46 PM..
 
Quote:
Originally Posted by djbell View Post
Having an empty Next list for an accessible (focused) context despite having next actions to do is counterintuitive, and this happens often in the current functionality. To use Ethan verbiage, it does not "shrink to fit."
This is precisely my biggest problem with the current definition of "next" as applied to parallel projects.

For me, there's nothing worse than getting a phone call out of the blue, switching to that person's context, and getting an empty list, despite there being available issues (tasks) to discuss.

An alternate way to mitigate this would be to add an available-task counter next to the context name in the context tree (as others have suggested elsewhere). That way I'd at least be aware that there's something hidden at a glance, even without having to select the context. But that's still a band-aid (albeit very nice one on its own) rather than an actual solution.
 
Quote:
Originally Posted by brianogilvie View Post
Otherwise you might find yourself making a few calls that are low down on your list in a parallel project (because the other actions are not in that context), and not getting to the 2 or 3 calls that are at the top of other parallel projects, and therefore the most important things to do to move those projects along.
That's a really neat strategy!

But I have trouble making it work. Maybe I've missed something -- is there a way I can see available tasks in context view not clustered by project?

If I switch from "next" to "available", I end up with a very long list, across dozens of projects. I don't have any grouping turned on, but I still find the available tasks listed in (project, priority) order. That means I have to look through the entire list to find the calls that are "at the top of other parallel projects".

Is there some way to bring the top tasks of projects to the top of the list?
 
Yay, with the latest update, Single Actions are now in Next.

I agree with everyone that the OF implementation of a Parallel Project is an Omni invention, and accept that by their own definition their secondary actions aren't Next. Hopefully a filter like pjc's algorithm shows up and makes them more useful.
 
Quote:
Originally Posted by djbell View Post
Maybe we should just name things in OF in ways they might make sense in plain English. Like GTD's definitions.
I really do not understand why you think the current implementation of "next action" doesn't make sense in "plain English." It does to me, but then reasonable minds may differ. This is why it makes sense to me:

A few pages before the statement you cited is DA's definition of "next action."

Quote:
David Allen, page 34 in paperback book -- "What is the Next Action? The 'next action' is the next physical, visible activity that needs to be engaged in, in order to move the current reality toward completion." emphasis added
I think there is a discernible difference in meaning between saying "the next action," as DA does, and "a next action," which is what I think is being proposed here.

I realize the above is just a semantic argument, but I am still opposed redefining "next action" to mean something other than the single action I have selected as the next action.

I understand what you want to do, and I think that would be a great addition.

Edit: djbell - I didn't see your latest post before I answered your previous one.

Last edited by dhm2006; 2007-09-15 at 05:13 AM..
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Only 1 action in projects? Why?? [A: View menu set to "Next Action"] brandall10 OmniFocus for iPad 2 2010-08-01 06:43 PM
No "New Action"/"New Context" menu items in 1.7? WCityMike OmniFocus 1 for Mac 4 2009-09-30 05:01 PM
Action status: "next action" and start dates dondo OmniFocus 1 for Mac 3 2008-08-06 08:48 PM


All times are GMT -8. The time now is 10:51 PM.


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