I’m having trouble creating a parallel project. For example, I created a new project and added three actions. However, no combination of the Mode (AUTO, Project) and the Sequential flag (checked or unchecked) seems to make any difference. In all cases only the first action is tagged as a “Next action”.
Things get more strange when adding a sub-project. When unchecking Sequential on the higher-level project, the first action in the project is tagged as a “Next action” and either the first action in the sub-project is tagged as a “Next action” (if the sub-project is not Sequential) or no actions in the sub-project are tagged (if the sub-project is Sequential).
Further, if the sub-project is not Sequential and I select the first Action in the sub-project to be Sequential (and I’m not sure what that means) the second Action in the sub-project gets tagged as a “Next action”.
Seems like something is broken. Or am I mis-understanding how things should work?
In GTDNext all tasks within projects are always sequential. You can individually select tasks within a project and force them to be next actions by using the “force next” option (or by clicking on the grey “n” and turning it green.
You can also click the Grey “n” of the project itself. This makes any new actions added to the project to have the “force next” option turned on by default.
So in practice, if you want all your actions in a project to be "next actions’ just click the gray “n” at the project level right when you make the project. All new actions added to the project will then be set to “force next” and be next actions.
Does that make sense?
The sequential check is used to designate if the project itself should be done in parallel or sequential to the other sub-projects. It does not control how actions within the project work.
Yes, it definitely gives a broken impression on me too, and although it is is not actually quite as broken as it first seems it is unnecessarily complicated and has unnecessary inconsistencies and unnecessary shortcomings (things that cannot be accomplished).
It would be more consistent if subprojects, too (tasks at all levels) followed the same default. And I would appreciate having a general app-wide preference setting for this default, because I find a parallel default to be more generally useful. A parallel default would also preclude mistakes (newcomers and/or stressed people “losing” tasks into the void), and therefore I would also recommend that the default default [sic] be parallel.
I am sure this is confusing for newcomers - and it is definitely inconsistent even if you know how it works - to have the same toggle for two entirely different kinds of purposes.
This is another unnecessary complication. Why not use the Sequential setting for both, consistently?
(You could still have the Sequential checkbox automatically ticked by default if you insist that the default should be sequential, but why on earth have two different checkboxes for it??)
Yes, I know I sound critical, but I am actually trying to help you get more customers and build an award-winning product. You have done quite well so far, and you have made a good start! Best of luck!
After more thinking and tinkering, I think I understand a little better. A few thoughts:
It would be nice if a project is tagged as 'Forced Next," all the actions and sub-projects within the project are automatically tagged as “Forced Next”.
It would be nice if there was some graphical representation when something has “Sequential” toggled (without having to look in the panel).
Still not sure I understand what it means if an action has Sequential toggled.
(By the way, the link to the video doesn’t work… a colon is missing after “http”.)
But I’m still having trouble figuring out a particular use case. Consider a project that has three actions:
This actions would need to occur in order. For example, the second cannot be completed before the first.
But now I want to change “Conduct interviews” into a sub-project and add the following actions:
2.1 Interview Ann
2.2 Interview Bob
2.3 Interview Chris
Now these three actions can occur in any order, but none of them can start until the first action is done. I can’t tag these as “force next” since the first action isn’t complete. I suppose I could remember to tag these as ‘force next’ after the first action completes, but this seems less than ideal.
Guess I’d really like a way to mark all the actions in this sub-project as “parallel” but not become active until the actions/sub-projects before it are complete.
Exactly. This is one of the current shortcomings; it is simply not possible. But this functionality could be provided very simply if only we could use the Sequential toggle for actions in the same way as we can for projects (parents) at all levels. In fact, the Force Next toggle is not even needed; parallel/sequential toggling could be more conveniently and consistently managed with just one single Sequential toggle (unmarked meaning parallel) that operates on actions and projects alike.
Indeed. And I think the developers have said that this will be provided. As far as I am concerned a green-gray icon could be used for actions and projects alike - plus maybe a yellow or pale green color to indicate a parallel item which is still on sequential hold because it sits under a gray (sequentially inactive) parent/grandparent etc.
This is probably the most common approach (Nirvana, MLO etc) but I personally recommend the “combo” (all-in-one) approach, where one single project type can have a variable number of parallel initial actions followed by a variable number of sequentially dependent actions, as it is now. But:
I would be perfectly happy only if I were able to have all my stuff default to parallel, where I would manually change the setting of those actions or parents that I want to follow sequentially after their siblings.
To a very large extent, although a toggle would still need to be used from time to time, this changing could be totally implicit/automatic - when we drag an action to a position after a sequential action it would itself turn sequential. In other words, it could mimic the sequential toggle setting of the preceding action in the list, in the same vein that the indentation works when you drag things in the outline mode. (And then you could still click the toggle when you have some exceptional case.)
HI PMD - Yes I see what you are trying to do. That’s a great use case thanks for taking the time to provide an example. We feel pretty good about how GTD handles sub-projects and how sequential works (Folke disagrees) but it certainty isn’t perfect yet. We will continue to work on it to add support for more scenarios and hopefully make it easier to understand. Really appreciate your feedback!
I don’t only disagree - I actually also agree with a whole lot of it
I think you have made some very wise and important decisions that I really think you deserve major credit for:
to begin with, the fact that you allow for both parallel and sequential actions in projects, and for parallel and sequential subprojects at all levels within larger projects. Kudos. Some apps have only parallel (e.g. Doit) and some have only sequential (e.g. Facilethings).
and then of course you have the unlimited hierarchies. Kudos.
the more uniquely fundamental difference - a key underlying feature - is the fact that you have made the control (the toggle) apply to the marked item’s relationship to its siblings rather than to the relationships between its children. Kudos. Huge kudos. This is extremely important. The more common approach, letting the toggle apply to the marked item’s children (as in Nirvana, MLO), is what ultimately makes those apps unflexible because they are unable to allow the user to vary the number of parallel and sequential items in the project. They allow only either all parallel or strictly one at a time. But your approach allows for any mix of initial parallel and subsequent sequential actions. Kudos again and again.
you have shown - just now in the last post, apparently due to @pmd’s excellent example - that you now appear to agree that being able to pre-plan which actions will become parallel when a sequential subproject becomes active is indeed a desirable feature. (In other words, the need to remove the Force Next toggle’s “hardwiring” of the action straight to its active list. Making it work indirectly instead, as I believe the Sequential toggle does for projects, will make the app much more flexible and useful.)
and you have said earlier that you will implement a visualization of parallel vs sequential subprojects. (This will also make the app much clearer and better. It is obviously just as necessary to see this clearly for subprojects as it is for actions.)
and you have said earlier that you will allow people to set parallel as a general default. This will make the app much easier to use for stressed simplicity lovers like me, and if you then also decide to set parallel to be the standard default for new users it will make the app much safer for them also (and they can set it to sequential themselves later, when they understand the dangers of it, if they really want it).
The only things I really disagree with are:
why have two toggles for parallel/sequential control when one is enough? (it is much simpler and clearer with just one; and I prefer the name Sequential over Forced (“not Forced” = Sequential), but regardless of terms used, why on earth have two different toggles? I just don’t get it.)
and why use the same toggle (Force) for also controlling defaults for new actions? (it is much simpler to understand the app if the toggle works consistently as a parallel-sequential toggle for the item itself, which seems to be the standard and original behavior, rather than sometimes also controlling the default setting for new items created under it.)
having a parallel default is much more essential than having a sequential default, so at least you need a general user option for this, as you have said you will, and preferably you will make parallel the standard setting for new users (much less risky; trust me)
having the same default (preferably parallel) at all levels (actions and projects alike) is simpler
I think a lot of the various pros and cons of these defaults (parallel or sequential) could be totally avoided if in the outline mode there were a “dragging” default (also serving as an “Enter key” default), letting the dragged/created task’s parallel/sequential toggle mimic the setting of the preceding task’s toggle whenever a task is created or moved into a certain position. Here is why: If people typically have a few parallel (green) actions at the top of the project, followed by a tail of sequential (gray) actions, then such a “dynamic” default would almost always mirror the user’s intentions, and whenever it sometimes does not, it is simple enough for the user to correct these rare cases by simply using the toggle. (I do not know why you have never even responded to this suggestion.)
So, at least we agree on a whole lot, even if it is not absolutely everything
Keep up the good work! And please do not give up now that you have come this far!
