Handle project type by task

[Hydro]

Hi

Currently we define project type when we add / edit project.

What do you think to handle this by task ?

For each project you define a project type by default. When you add task to this project, it take project type by default and you can change.

For example, let’s take a project A with parallel type. When you add the first task, it take parallel type and appear directly on focus.

When you add task 2, same thing because parallel with task 1.

Then you add task 3 with sequential type. Everdo ask you witch task to take as reference, you select task 1 (maybe multiple select possible).

When you complet task 1, task 3 appear on focus list and type for this task is set to parallel.

That way you can easily make complex project.

For example, I have a lot of project that have parallel tasks but sequential tasks too and currently I can’t use project type feature.

In case a reference task is delete, task return to project default type.

What do you think ?

[manu]

I once used a GTD app that supported something like that.
In the app you can select multiple actions and then set them to parallel. This way all actions of this group show up as next action, but there also can be more actions that are sequential to the action group.

It added a lot of complexity that the programmer had to deal with. I didn’t use it that much, because my projects seldom are planend out in such detail that I would / could make use of this feature.

My personal opinion is: Nice to have, but probably overrated

[Andrei]

Suggestions for extending the planning capabilities of the app get brought up from time to time. Sometimes it comes in a form of hierarchical projects, sometimes it’s dependencies between tasks. Here are some of my thought on this. I’m sure there’s more on the forum, these are just the top search results.

Please consider supporting hierachical checklist

Would be so great to see this done properly in software. I just don’t see a good way it can be done yet, nor have I seen a good reference implementation. Multi-level projects are not the solution here, I believe. For me this problem is currently solved with a pen+paper flowchart. It’s easy to create, it’s easy to throw away when plans change. It’s easy to create actionable Everdo projects based on such plan. The way I see it there are two modes in GTD: planning and execution. Everdo focuses …

Dependencies between separate tasks/projects

Hi Alexey, Thanks for you feedback! You are right. I thought about this problem for a while and I think it can only be properly solved by supporting a tree-like project structure. It would be awesome of course to have this ability built-in. But I’m realizing it’s both very complicated technically (especially given the existing design) and also unnecessary most of the time. This makes the feature a poor target to apply effort to, at least at present time. So for now the decision is to leave c…

In short, @manu is spot on: the complexity vs the usefulness in the context of a GTD app of complex planning makes similar features unlikely.

Regarding the specific mechanic suggested by @Hydro, it does look simple when creating the items or assigning them to projects, but a much more difficult problem would be to visualize the resulting project and allow for editing of the dependencies in a reasonable way. This is where the feature quickly gets to much out of the scope of improving core GTD capabilities.

[Hydro]

Thank for explain your point of view.

Do you plan to add one level of subproject ?

[Andrei]

I think it’s unlikely.