@lewa1983

Hi,

Thank you for your feedback! We are considering to add this feature. But we need some time to develop it.

Shall you need any help or have additional questions, please do not hesitate to contact me back.

Thank you for your support!

Best regards,
Doit.im Team

@wendy_only

When you say "considering" I feel a bit uneasy, but also hopeful. You (i.e. Doit: michelle) has said you are currently "making a design for it" (http://help.doit.im/topics/1328) and she has also referred to this as "task dependency" (http://help.doit.im/topics/545). Is it possible that we are all talking about the same thing, but simple misunderstanding each other?

The root of the problem is this:

In a project there can be many actions that will be possible/relevant only at a later stage, after some of the first actions in the project have been completed. (These are the "dependent" / "subsequent" tasks; same thing, different word). These tasks you do not want showing up on any of the main lists (Next, Waiting, Scheduled or Someday). They should only be visible in the project for the time being (until the become possible/relevant). I think everyone agrees on this.

Now, as for the question of by what kind of mechanism these dependent tasks are initially classified as "dependent" and by what kind of mechanism they are later "activated" and shown on their respective main lists, there have been several alternative suggestions:

One suggestion has been to make all this entirely manual: In the project view there could be a checkbox or similar feature by which the user selects which tasks are to be shown on the main lists and which ones are "dependent", not visible on the main list, but visible within the project only. This solution is good enough. It solves the root of the problem completely. But many people prefer to have a bit of "automation" in addition to this - that the next task in line is automatically moved into the visible state when there is nothing more ahead of it, blocking it:

I believe the best solution for also providing automation is to let new tasks be visible by default, just like today, but allow users (in the project view) to "hide and prepare" tasks for "automatic activation" later, by initially moving (dragging) them manually down to a "Subsequent" portion of the project and placing them manually in the correct order (sequence). From that "Subsequent"/"sequential" portion of the project, the first task would be automatically become active/visible (moved to the "Current"/"parallel" portion of the project) ) when there are no longer any other "Current" (visible) tasks in the project.

This solution has several advantages over other automated solutions. It is very simple for both new and old users to understand. Everyone can go on using projects just like before, if they like. A task will never be accidentally "lost in the darkness" when you move it to a project - it will still always show up on the main lists unless you deliberately hide it in the sequence of the dependent actions. You can easily arrange your tasks to show up sequentially only one at a time automatically, if that is what you want. And you can have more than just one task active/visible at the same time, which is the typical case in real-world project - some tasks, but usually not all.

There is also another, more crude, less flexible, and more confusing solution, which requires users to make an initial choice of whether this project will be "sequential" (always exactly one task at a time visible) or "parallel" (all visible, just like Doit does it today). This not only confuses new users, but has the major disadvantage that real-world projects still cannot be represented at all. Real-world projects usually have more than one action that is possible. (And David Allen also explicitly says that you must do so, if anyone cares. This is particularly important if the actions are actionable in different contexts.)

@Folke

Hi,

Thank you for your suggestions with details.

Yes, It is a bit uneasy. We have found some solutions, but they are not perfect. The way need to be easy to use and understand but aslo could not be much difficult to develop.

The best solution which you suggest seems to be the best one now. Thank you.