Quote:
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.
Quote:
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. ;-)