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.)