Recommendation: Parallel

Technically speaking, it is perfectly true to say that it does not matter if the default setting for tasks in projects (or “nodes” within “parent nodes”) is “parallel” or “sequential”. As long as that default is user correctable for the individual item you can always get the “nodes” set up the way they should be.

But here are a few reasons - I think important reasons - why I think it would be wise to seriously consider having “parallel” as the general default.

Noob proof. Most normal people find it complicated to even hear the words sequential and parallel, and have no idea what this is for even if they get a good explanation. I have read posts in other app forums (Nirvana and Zendone) where people wonder “where did my tasks disappear”, “why it is so complicated” and “what is it even for”. A straight parallel default is definitely much safer and much more intuitive to most people. And those of us “nerds” who want more control will find the app’s “sequential switches” easily enough.

Statistically more frequent, probably. I believe it to be the case for most people - even for us productivity nerds - that the number of parallel tasks may well be larger. This would be so for some very frequent reasons:

  • many people use “projects” not only as “real projects” but also as convenient “folders” (containers) that simply contain similar tasks, e.g. gardening tasks, bookkeping tasks etc. These tasks typically have no dependencies between each other and can be done in any order (parallel).
  • many people do not plan their “real projects” very far ahead; they enter just a few tasks at a time, and often these can be none in any order (parallel). The number of dependent tasks “on hold for later” (sequential) is quite small.

Requires fewer visits to the project for adjustment. If a sequential task is dropped onto a project, it is almost always necessary to also visit the project to adjust its list position reasonably exactly. So, simultaneously changing its status from parallel to sequential requires no extra visit to the project. Conversely, if a parallel action is dropped onto a project, no visit at will generally be needed - if only it actually lands as “parallel” it is not position sensitive; you’re ready to go!

Fewer forgotten tasks. Even people who fully understand the mechanics will sometimes forget things. If tasks land as sequential by default, and the user forgets to go to the project and adjust a task’s list position, there is a risk that the task will be forgotten for a long time, too long perhaps. Not so if the default is parallel. It will then immediately show up on its intended list (Next, Waiting, whatever), and if this was incorrect (if the task is actually not “current” just yet) the user can always easily correct the mistake if it irritates him/her (by setting it to sequential and moving it to its correct list position) without any harm or danger having arisen.

Major exception. The only case I can think of - but a major one - where the default should be slightly different is when tasks are created or moved Workflowy-style in the All Projects view. In those cases I think it would be appropriate to default to the setting of the neighboring or preceding tasks. If it is placed among parallel tasks (or in an empty container) it will default to parallel; if it is placed among sequential tasks it will default to sequential. (I think it is fair to assume that if any sequential tasks even exist then this user knows how it all works, and therefore defaulting to sequential if placed among sequential tasks will typically be exactly what the user wanted.)


I would agree with @Folke on this. It would certainly be easier, and I agree that most of the projects I create do run parallel, not sequential, and that when I do make a sequential list, I usually brainstorm it first, then drag and drop it into the right order. With a parallel list, I’m just brain-dropping, and the order doesn’t matter, as long as it stays in next.

Really solid suggestion!

Come to think of it, I think the best name for parallel would be to have no name for it at all in the UI, or simply Normal.

This is because to most people this is normal, i.e. what they would have expected - just like in Windows or Google Drive or many other task apps. This “normal” behavior only needs a more technical definition (such as parallel or first or initial or forced next) if and when a user starts to dig into the automation capabilities (sequential) and needs to compare the effect of these alternatives. But up until that point such technical terms only cause confusion.

So, if parallel is called Normal, then the alternative (auto-sequential) setting could perhaps be called something like

  • Automatically On Hold (until preceding item has been completed)

And it might be very wise to also have a third option, particularly useful at the higher levels for inactivating entire projects etc manually until a firm explicit review decision is made to activate or reactivate them:

  • Firmly On Hold

I just created a post to give my thoughts on several different threads on similar topics - this is one of them

It’s here. Some thoughts on GTDNext next action logic