Some thoughts on GTDNext next action logic

Yes, to keep it uniform, consistent and simple and reliable. Always the same principle - treating all these “nodes” as “things to be done” and not get lost in what level they are on or whether we call them sub-this or sub-that or action or fraction or whatever. Simple and consistent.

The way I see it these parallel-sequential relationships are between the immediate children of a parent. Always. Period. Some of the children will go first (in parallel; in any order) and others will have to wait until the first ones are done (sequential; will be dealt with, “turned on”, one by one). This is complicated enough already - but very nice indeed and I like it, and I know you do to. It is what the two of us, and others, have argued so much for on the Nirvana forum. And GTDNext actually has it, as long as the children do not have any children of their own…

So I cannot see why James and Sergio feel they must invent yet another, totally different, contradictory, complicated and dysfunctional approach for when these children in turn have their own children. It is totally beyond me. Say I have a project which involves buying some land, building a house etc and finally “plant the garden”. Say this last one is a so-called “action” (with no children) at the moment, and it is placed last in line and it is gray (sequential; not time for this yet). Then one day I start thinking about all this future planting, and dream up some specific things I realize I will need to do at that stage, say “buy rose bushes”, “buy shovel”, “read gardening magazine”, so I add those under “plant the garden”. Why on earth should even one of these sub-thingies show up on the next list now already! Their parent was still on hold (sequential; gray), fgodsake! The whole planting thing is on hold and always has been!

It seems like such a waste of the devs’ time to persist with that extra development, and a terrible waste of a good app. Makes me want to cry. Like building a gold castle and then when it is built throw it in the ocean.

Yes, my suggestion is very simple:

  • put green/gray switches on basically everything - all levels and all “types” (next, waiting etc)
  • let the green setting mean “to be done first among the siblings, in parallel with any other green siblings it may have, before any of its gray siblings”
  • let the gray setting mean “to be done only after all green siblings have been done; then turned green automatically one at a time in the order they are listed; only when turned green the settings of its children, if any, will apply”

That’s it. A task needs to have “the green light” all the way down from the top to get listed on any of the “current” lists (Next, Waiting etc), else it will stay in “incubation” (as DA would have said).

New, additional suggestion:

The green/gray icon could perhaps be better placed on the left, following the indentation. This will make it much easier to see which items are siblings, i.e. see the tasks that the green/gray setting is relative to. All sibling icons will then be on a straight vertical line, between parent nodes that have their icons further left.

And - I might as well repeat this - concerning defaults:

  • in outline (Workflowy) mode, when a new “line” is created using the Enter key, an appropriate default for the green/gray setting would be to simply copy that of the original “line”

  • in outline (Workflowy) mode, when dragging an item to a new position, an appropriate default would be to simply copy the green/gray setting if the preceding sibling. If there aren’t any siblings, default to green.

  • when “tossing” items onto a parent node name (e.g. a project name), using the left menu or dropdown list etc (without positioning the item), the appropriate default is green (as it already is, I think)

Those are the only defaults necessary, and they will tend to match the user’s intention most of the time, and can be toggled whenever desired.

The current feature for parent nodes - to click the green/gray icon to force a green default whenever you enter a new task under this node - is hardly of much use, especially not if the other defaults above are all in place, and stands in the way of the simple and general solution for the green/gray icon outlined above.

As for the “Force Next” checkbox (the edit pane equivalent of the green/gray toggle), it would be best to invert it and call it “Sequential” (gray). This is so much easier to understand. (When the Sequential checkbox is not checked, the task will be parallel/green.)

A final word on development workload and complexity

If the above strikes anyone as complicated, it is because the description is detailed. Any alternative is even more complicated. Look: In the example with “plant the garden” above there is simply no way that anyone will accept to see “buy rose bushes” etc on the Next list now, maybe one year too early, so the developers will definitely need to devise a way, various switches or whatever, to make it possible to turn those off. There is no way they can escape that development work or the inherent complexity of having a multi-level flexible hierarchy. The only choice they have is whether they want one single uniform solution, easy to understand and to use, or a “jumpy” “mixed” solution that forces the user to use totally different sets of switches to accomplish this same thing depending on whether the node has children or not. I think the choice is obvious.

I get what you are saying and I agree. I would want it to work as you described and I feel this just makes sense. I try not to use “common sense” since I think it no longer exist in this world. lol

Common sense is certainly not the norm today! :smile:

@James - If the logic that is used in GTDNext is that all projects will be treated as Sequential projects by default, then will you be eliminating the Sequential check box that shows in the detail panel? It seems like it’s not needed if each project will default to Sequential.