add a list of order-dependent subtasks to a task

[Lionel Dricot]

Often, I want to add to a task a list of subtasks that should be completed in a specific order. In the task "Newtonmas gift for Albert", I want to have, at the end, the following tree :

Newtonmas gift for Rose
  -> Put the gift under the tree
     -> Pack the gift in a nice paper
        -> Buy the gift.

There's currently no easy way of doing that. I've no idea on how we could provide such a functionality to the user. This bug is open to discuss UI suggestion.

[Jonathan Lange (jml)]

OmniFocus has a nice way of doing this.

For any given task, you can specify whether the tasks below it are to be done in sequence (that is, one after the other), or in parallel (that is, the order doesn't matter). This can be toggled just by clicking an icon on the parent task.

They go a step further and let you see only the bottom-level tasks that are active. Thus, for example, there's a view that would show only "Buy the gift" and any other bottom-level tasks.

[Paul Natsuo Kishimoto (khaeru)]

@Jonathan: "see only the bottom-level tasks that are active" — have you never used the GTG work view?

I sometimes have order-dependent subtasks, but so far I have gotten by with:
* Setting dates, or
* Naming the tasks like "1: Buy the gift", "2: Pack the gift in a nice paper" so they sort in the right order.

These techniques can also *mix* with unordered tasks...for example I have one task with some ordered subtasks ("1: ...", "2: ...", "3: ...") and some other, unordered subtasks. I can also see if I have done things out of order ("1: ..." and "3: ..." remain = "2: ..." was done out of order). As techniques, users have to be taught to use them, but I think they are better than trying to make the task model anticipate all the possible ways people use tasks. Then the task model gets very complicated just to add incremental features.

One small change could help: automatically alter task titles to teach the user how to order things. Suppose we had four tasks (in alphabetical order):
* Bow
* Jump
* Sit down
* Stand up

But we wanted them in the order:
* Stand up
* Jump
* Bow
* Sit down

If I dragged "Stand Up" before "Bow", GTG could rename those "1: Stand Up" and "2: Bow" respectively to match my intended ordering:
* 1: Stand Up
* 2: Bow
* Jump
* Sit Down

Drag "2: Bow" after "Jump" (or the opposite):
* 1: Stand Up
* 2: Jump (renamed)
* 3: Bow (renamed)
* Sit Down

...after seeing GTG do this for them, even a new user would think, "Oh, right—I can use numbers to keep some of my tasks in order!"

There would have to be some decisions made about how this worked, e.g.:
(Bow, Jump, Sit down, Stand up) → drag "Sit down" to last → (1: Stand up, 2: Sit down, Bow, Jump)
OR
(Bow, Jump, Sit down, Stand up) → drag "Sit down" to last → (1: Bow, 2: Jump, 3: Stand Up, 4: Sit down)

...but I would like this approach.

[Paul Natsuo Kishimoto (khaeru)]

Another thought:

If the user tries to drag-reorder two tasks that are sorted a certain way because of their *date*, they could be shown a dialog:

It looks like you want to do the task *Buy the gift* /before/ the task *Pack the gift in a nice paper*, but it has a /later/ due date. Do you want to change the due dates of these tasks?

Buy the gift [ date entry ]
Pack the gift in a nice paper [ date entry ]

[ CHANGE DATES ] [ CANCEL ]

[Lionel Dricot (ploum-deactivatedaccount)]

Paul > I don't understand your need for inserting numbers in the title. I do that by drag-n-dropping Stand Up on Jump then Jump on Bow ten Bow on Sit Down.

It makes it :

+ Sit down
  + Bow
     + Jump
         + Stand Up

and only "stand up" appears in my workview, which is exactly what I want.

AFAIK, this bug is only bout the fact that it's inconvenient to do that drag-n-drop work.

[Paul Natsuo Kishimoto (khaeru)]

Ah, I see—I guess I was misled/misinterpreted.

In that case, maybe modify the quick add syntax. E.g. " > " or something could recognized as a separator. You could type:

Newtonmas gift for Rose > Put the gift under the tree > Pack the gift in a nice paper > Buy the gift.

Or, in editing the task "Newtonmas gift for Rose", you could add a subtask called "Put the gift under the tree > Pack the gift in a nice paper > Buy the gift"...that would be replaced by "Put the gift under the tree", and the other sub-subtasks would be created.

[Matthew Rasmus (mrasmus)]

Paul Kishimoto wrote:
> Ah, I see—I guess I was misled/misinterpreted.
>
> In that case, maybe modify the quick add syntax. E.g. " > " or something
> could recognized as a separator. You could type:
>
> Newtonmas gift for Rose > Put the gift under the tree > Pack the gift in
> a nice paper > Buy the gift.
>
> Or, in editing the task "Newtonmas gift for Rose", you could add a
> subtask called "Put the gift under the tree > Pack the gift in a nice
> paper > Buy the gift"...that would be replaced by "Put the gift under
> the tree", and the other sub-subtasks would be created.
>
I just opened up a bug report dealing with an overall look at quick add
syntax issues (bug #509761). Can you post this there? I like this idea.

[Bryce Harrington (bryce)]

Most wiki's have an automatic syntax where it converts a sequence of lines prepended by numbers into an "ordered list" (<ol>):

1. foo
1. bar
1. baz

Or

1. foo
2. bar
3. baz

For gtg, I think it would be convenient and discoverable to do something similar. The code that auto-interprets '-' as an indicator of a new task could be extended to recognize '\d' similarly, and set up the subtask tree accordingly.

So for instance, I'd like to be able to type something like this:

- Paint table
 1. Decide whether to paint table blue or red
 2. Buy paint, brushes, drop cloth
 3. Paint first coat on table
 4. Paint second coat on table

And gtg turns the above into the following structure:

+ Paint table
  + Paint second coat on table
    + Paint first coat on table
       + Buy paint, brushes, drop cloth
          + Decide whether to paint table blue or red

It would be extra cool if it could handle multiple dependencies. In other words, instead of buying all the items as one task, what if we had to go to three different stores and thus had three separate tasks, all of which need to be done before we can do any painting? Maybe:

- Paint table
 1. Decide whether to paint table blue or red
 2. Buy paint
 2. Buy brushes
 2. Buy drop cloth
 3. Paint first coat on table
 4. Paint second coat on table

And then represent this as: (?)

+ Paint table
   + Paint second coat on table
      + Paint first coat on table
         + Buy brushes
         + Buy drop cloth
         + Buy paint
            + Decide whether to paint table blue or red

Anyway, just some rough thoughts. I'd definitely like to see this feature too.

[Matthew Bassett (hewbass)]

Why not allow the "starting on" and "due by" fields to select tasks as well as dates?

E.g. "starting on" a task means that this task is a follow on task from the one selected in the "starting on" field (and thus should not appear in the work view until that task is complete).

Selecting a task in the "due by" field makes it a follow-on task from this one (i.e. it will not appear in the work view until this one is completed)

[Bryce Harrington (bryce)]

Matthew's idea is not a bad one. Internally, we'd still represent task parental relationships the same way, but the UI that the user sees would communicate instead of that the parent task begins on such and such a date, that it's going to start only after <child-task>. Perhaps this should be split out to be a separate bug discussion.

[Elrond (elvenlord.elrond)]

Taking Matthew's idea to the next level:
Have explicit dependencies.

 1. Decide whether to paint table blue or red
 2. Buy paint (a)
 2. Buy brushes (b)
 2. Buy drop cloth (c)
 3. Paint first coat on table

would mean:
- 2a, 2b, 2c depend on 1.
- 3 depends on 2a, 2b, 2c

Pro:
- Very flexible, could even allow to depend on tasks not in the current "main task". For example all the 2* tasks could depend on "create money".

Cons:
- Needs loop detection. ("A depends B, B depends A" <- not good!)
- Selecting the task to depend on might be a UI challenge.
- "Display Sorting" according to a directed graphs isn't straight forward either