[curt.clifton]

Originally Posted by al_f

The workaround of using "available" is fine, but the problem is that your definition of "next" doesn't match David Allen's definition of "next" when it comes to parallel projects or projects with action groups (or, at least, it doesn't match how a large number of people interpret David Allen's definition, myself included).

Unfortunately, it does match the interpretation of a large number of other people, myself included. So I guess the current situation is fortunate for those of us in this camp, but unfortunate for Omni since they can't please all of us. Perhaps they should call them uffish and beamish actions, then we can all interpret the words as we see fit (with apologies to Lewis Carroll).

[Chris]

Originally Posted by jasong

Part of the issue is that actions are tied to projects, not action groups. In context mode,

[_] Visit Home Center and review color combos

is displayed with a project of “Paint Living Room” rather than “Decide on colors”. It would help, visually, to show the hierarchy, e.g.

[_] Visit Home Center and review color combos ... Decide on colors (Paint Living Room)

[_]Visit paint store for tarp, brushes, tape, etc. at painting store ... Buy Painting Supplies (Paint Living Room)

[_] Move items to center of room ... Prepare Living Room for painting (Paint Living Room)

Does this expectation make sense? Am I missing something important in how I've planned my project(s) and want to act on them?

In thinking about this, I would like to see the action group appear as part of the action name in context mode, not as part of the project. (I think that overloads that little area with too much info.) So I would like to see this displayed as:

[_]Visit paint store for tarp, brushes, tape, etc. at painting store (Buy Painting Supplies) .... Paint Living Room

So "(Buy Painting Supplies)" would be appended to the action, and "Paint Living Room" would show as the project.

[al_f]

Originally Posted by curt.clifton

Unfortunately, it does match the interpretation of a large number of other people, myself included. So I guess the current situation is fortunate for those of us in this camp, but unfortunate for Omni since they can't please all of us. Perhaps they should call them uffish and beamish actions, then we can all interpret the words as we see fit (with apologies to Lewis Carroll).

Or snark and boojum actions, perhaps. :)

I've had this debate with the ninjas and that's the reason they gave me for the current setup: roughly equal numbers of people had requested the two different ways of handling "next", so they made the system work as it is now. Personally I have no problem with just continuing to use "available".

[jasong]

Chris, that's a perfectly acceptable solution, especially since there's so little space in the project field anyway.

[jasong]

Curt, can you describe your understanding of "next" actions vs. "available" actions? Perhaps you've already written about it elsewhere (I know this is an ongoing discussion, and I'm thinking I must be missing an important detail in why half the folks want "next" and the other wants "available").

[Ken Case]

Originally Posted by al_f

The workaround of using "available" is fine, but the problem is that your definition of "next" doesn't match David Allen's definition of "next" when it comes to parallel projects or projects with action groups (or, at least, it doesn't match how a large number of people interpret David Allen's definition, myself included).

I guess this isn't surprising, since it's used both ways in the book, depending on whether you're talking about the next action of the project or the next actions of individual components of a project.

OmniPlan's uses the term "next action" to refer to the next action for the project itself, as used on page 58 of David Allen's Getting Things Done:

Once you've generated various thoughts relevant to the outcome, your mind will automatically begin to sort them by components (subprojects), priorities, and/or sequences of events. [...] Finally [...], you focus on the next action that you need to take to make the first component actually happen.

Does that make our perspective more clear?

[jasong]

Ken, I think the interpretation of that passage can be different, depending on how you define “first component” or subproject (what OF calls action groups).

If you define it as “one of a sequential set of subprojects, of which the top subproject is the first in the sequence” then the “next action” of a project is in fact the first available action of the first subproject. (And therefore the "next" menu works correctly, and "available" works incorrectly.)

If you define it as “one of a parallel set of subprojects, of which any of the subprojects can be done first”, then “next action” of a project is actually the first action in whatever subproject you chose to start with. (And therefore the "next" menu works incorrectly, and "available" works correctly.)

If my painting project is sequential, “next” shows the right action. If my painting project is parallel, “next” shows only one of the possible next actions. Therefore “next” is only actually “next” for some projects, not for others.

If you automatically switched “next” and “available” actions based on sequential and parallel, perhaps we'd only need the one “next” popup.

Related, a problem arises in OF that I'm unable to focus on a particular subproject, and therefore unable to see the next action for that subproject. If I could focus on a subproject/action group, then “next” has meaning again, automatically.

[curt.clifton]

Originally Posted by jasong

If you define it as “one of a sequential set of subprojects, of which the top subproject is the first in the sequence” then the “next action” of a project is in fact the first available action of the first subproject. (And therefore the "next" menu works correctly, and "available" works incorrectly.)

I don't see any way in which the definition of available can be construed to be wrong in the current version of OmniFocus. It derives directly from the definition of sequential and parallel. For a fully sequential project (project and all contained action groups are sequential) there can only be one available action. If there was more than one the project would have some parallel activity.

Originally Posted by jasong

If you define it as “one of a parallel set of subprojects, of which any of the subprojects can be done first”, then “next action” of a project is actually the first action in whatever subproject you chose to start with. (And therefore the "next" menu works incorrectly, and "available" works correctly.)

I wonder if you're misunderstanding parallel and sequential. Next action in OF works exactly as you describe that it should. You choose which subproject to start with by dragging it to the top of the list of parallel subprojects (or using the 'u' for up and 'd' for down keys if you'd rather). The first available action of the first "subproject" is the one next action for the project.

In the passage Ken quotes, Allen talks about the "next action" of the "first component". "Component" is singular, as is "next action". That's precisely how OF works. In OF the "next action" for a project is the top-most available action.

Some people want "next" to mean the first available action of every action group. Others want it to be the first available action in each context. Others want all parallel actions of the "one" next action to also be considered next actions. There are reasonable arguments for each definition, many of those arguments based on the gospel according to Allen. This argument is likely to be never ending. As such, I've come to the conclusion that letting "next" be singular for each project makes sense and is a useful filtering mechanism.

I almost always work from the Available view unless I'm feeling a particular lack of focus. In that case, the Next view narrows my choices dramatically. Also, if I think Available is showing too many things, well, I just structure my projects to introduce additional dependencies. They may not be actual dependencies--I don't really need to post my lecture notes before printing quizzes, for example--but they are practical dependencies since I can't do both at once and both are done in the same context.

If we don't get hung up on terms, then the uffish action of a project is the single top-most beamish action. A beamish action is any action that is not blocked. (Where "blocked" is defined recursively as a function of parallel and sequential projects and action groups. The definition is left as an exercise for the reader. Man, I must be an academic. ;-)

[brianogilvie]

Originally Posted by al_f

The workaround of using "available" is fine, but the problem is that your definition of "next" doesn't match David Allen's definition of "next" when it comes to parallel projects or projects with action groups (or, at least, it doesn't match how a large number of people interpret David Allen's definition, myself included).

However, it does match how many other people interpret "next action," myself included. Since the available filter matches what you want, it seems pointless to argue about terminology--though it is sometimes more fun than actually getting things done! :-)