Original Question by Proximo on 5/1
Not sure what this is for?
Great point. We need some help prompts or maybe we should change the name. The idea is to allow users to take an action that is not currently a “next action” and force it to appear on the “next action” list. This allows for more than one action in a project to appear on the “next action” list.
In other words, have more than just one next action per project. This is great and essential, and is a major improvement over Nirvana, Omnifocus and MLO, who all have the rigid “either-one-or-all” concept (i.e. sequential vs parallel). Only Zendone (and GTDNext) have made the effort to provide a flexible combo approach.
See further discussion here about possible adjustments to “Force Next” (or whatever the name will ultimately be):
http://gtdnext.uservoice.com/forums/246700-general/suggestions/5881093-comments-do-not-seem-to-work-or-do-they
The Next and Force Next logic needs to be exactly the same regardless of whether the items in the project are individual actions or are entire subprojects full of actions and subsubproejcts etc. The first item (task or subproject) in a project is automatically “ready” (Next). Additional ones can be Forced Next (also “ready”). But the rest are not “ready” to be taken on until the others have been completed, and should not be shown on the Next list (or any other list). Correct?
As it is now, this logic does not work in the app. It gets “circumvented”. Even subsequent non-Next items tend to be represented on the Next list in some cases. This happens when the item is a subproject. Then the first action within that subproject is shown on the Next list even though the subproject as a whole is not “ready” yet.
Maybe this topic requires a separate thread, I don’t know, but I assume it is just an oversight. @James, does this make sense to you?
I just replied on the other thread you brought up over here. Thanks!
I believe the name “Force Next” is quite misleading, and should be changed.
My suggestion would be something like “First/Parallel” or “Initial”.
The opposite, if shown, would then be something like “Later/Sequential” or “Subsequent”
Why?
-
I would avoid the word Next, since it is not necessarily a Next action (for me to do). It could be a Waiting For action (for someone else to do) or any of the other GTD categories (Nirvana “states”). It will be apparent enough from the background color (or other similar indicator) what kind of task this is and on which of the “current” lists it is on.
-
If you fix the “loophole” and allow nodes at all levels (i.e. subprojects and other higher levels) be put on hold and be auto-sequentially “released” only after their “first/parallel” siblings have been released, just like at the lowest level today, then choosing the “force next” option will not necessarily mean that the item will be put on the next list or any of the other “current” lists immediately. This listing will occur only when the item’s parent becomes active, but not while the parent is still on hold. This is why a word such as “first” is good. It conveys the idea without misleading anyone to think that “first” is necessarily “now”. The “green” indicator could (or should) have a different color (e.g. pale green or yellow etc) while the node’s parent is still on hold. This would make it possible to see in the All Projects view which tasks are currently on the “current” lists (green indicator), and which of the remaining ones are marked to become first among their siblings (yellow) or sequential (gray).
If you decide to change the default to “parallel”, which I understood was a thought you had under consideration, and which I actually think is a wise idea (for other reasons), then you could have the “force” box pre-checked for convenience. Or change its name to the opposite (e.g. Later/Sequential) and inverse the function. What you can also consider, to make the alternatives quite clear to users, is to explain both what the checked and unchecked alternatives mean or even have “radio buttons” for the two alternatives (“First/Parallel” vs “Later/Sequential”.)
Another thought regarding defaults. When entering or moving tasks in the “Workflowy mode” you could, as a default, let new tasks assume the “force” setting of the preceding task in the list (quite similarly to how the automatic indent/outdent logic also works). It is easy enough to change the setting if it is wrong (just one click), but every click saved can be useful. I believe that people will tend to have their gray tasks at the end, as this is more intuitive (chronological). This means that when people deliberately insert a task at a particular place among gray tasks it is usually for sequential execution. And - very important - for tasks “tossed in” (without placement; e.g. by selecting a parent node from a list or by dropping it on a heading in the left menu) I think the default must always be “first/parallel” both for safety reasons and for convenience (and they should also be placed at the top for visibility, but that’s a separate topic).