Sub-tasks should be ordered and orderable

[Raphaël Hertzog]

In the normal view, sub-tasks always appear in the order in which they have been created. Drag & dropping allows one to reorder the sub-tasks but it's not stored. If you regenerate the view (change a tag selection for example), the sub-tasks are again in their original order.

Note also that order of tasks in the work view is weird with sub-tasks of a given task sometimes separated by other tasks. I'm not sure what the right order should be.

[Michael Leuchtenburg (dyfrgi)]

This may be a separate bug.

Sub-tasks in the normal view are shown in the order they're entered in the parent task. However, the order they're shown in work view varies. The result is that if I have a task for which there are several subtasks that must be done in order, I have to play games with subtasks to make the tasks show up properly. Maybe this is the "right" way to think about things, but there are many ordered tasks that I don't think about in that way.

For instance, I have to set up a new SVN system. The steps are install Debian, set up SSH, install SVN, copy backed up SVN database over, import SVN database. To make this work in GTG, I'd have to structure the tasks like this:
- Set up new SVN system
  - Import backed up SVN database on k3
    - Copy backed up SVN database to k3
      - Install SVN on k3
        - Set up SSH on K3
          - Install Debian on K3

Not exactly intuitive, plus it requires tons of clicks to set up all the subtasks.

[Bertrand Rousseau (bertrand-rousseau)]

I think it is a separate bug. It's actually an example of "dependence
by sequence". You must do certain list of things one after the other.
So strictly speaking, right now you have to make substasks to express
this dependence. Maybe we could implement a kind of particular
typesetting that allow to express this directly (numbered list?). I
suggest you open a new bug explaining this.

On Wed, Jul 15, 2009 at 7:06 PM, Michael
Leuchtenburg<email address hidden> wrote:
> This may be a separate bug.
>
> Sub-tasks in the normal view are shown in the order they're entered in
> the parent task. However, the order they're shown in work view varies.
> The result is that if I have a task for which there are several subtasks
> that must be done in order, I have to play games with subtasks to make
> the tasks show up properly. Maybe this is the "right" way to think about
> things, but there are many ordered tasks that I don't think about in
> that way.
>
> For instance, I have to set up a new SVN system. The steps are install Debian, set up SSH, install SVN, copy backed up SVN database over, import SVN database. To make this work in GTG, I'd have to structure the tasks like this:
> - Set up new SVN system
>  - Import backed up SVN database on k3
>    - Copy backed up SVN database to k3
>      - Install SVN on k3
>        - Set up SSH on K3
>          - Install Debian on K3
>
> Not exactly intuitive, plus it requires tons of clicks to set up all the
> subtasks.
>
> --
> Sub-tasks should be ordered and orderable
> https://bugs.launchpad.net/bugs/345575
> You received this bug notification because you are a member of Gtg
> developers, which is the registrant for Getting Things GNOME!.
>
> Status in Getting Things GNOME!: Confirmed
>
> Bug description:
> In the normal view, sub-tasks always appear in the order in which they have been created. Drag & dropping allows one to reorder the sub-tasks but it's not stored. If you regenerate the view (change a tag selection for example), the sub-tasks are again in their original order.
>
> Note also that order of tasks in the work view is weird with sub-tasks of a given task sometimes separated by other tasks. I'm not sure what the right order should be.
>

--
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : <email address hidden>
tel : [phone]

[Lionel Dricot (ploum-deactivatedaccount)]

I don't really understand what we can do to solve this bug. It seems rather general and vague and I don't see any "solution".

[Raphaël Hertzog (hertzog)]

On Fri, 25 Sep 2009, Lionel Dricot wrote:
> I don't really understand what we can do to solve this bug. It seems
> rather general and vague and I don't see any "solution".

What is vague in « remember the order of sub-tasks » and update it
when the user re-orders the list ?

Cheers,
--
Raphaël Hertzog

[Bill Huffman (huffman)]

I tend to think in structured form, not in linear form. It is very important to me to be able to order tasks and subtasks in an order that makes sense to me - not alpha, not date, not lots of things. Drag-n-Drop would do that nicely, except that it doesn't work. If I drag a subtask to somewhere, a line shows where I think the subtask will drop. But then it appears at the end of the list at that level anyway. This makes it much harder for me to "think into the system" and I'd like to see it fixed.

So, I'd say, when no column is set with an up/down arrow, tasks and subtasks can be arbitrarily reordered by drag and drop. Whenever an arrow is made to appear, tasks are reordered into buckets depending on the new criterion. Within each bucket, the order is whatever it was before. I know this general concept under the term "stable sort". That means if I want to sort first by due date and then by alphabet, I sort first by name then switch to by due date and I will get the combination order. If I want (as I do) to sort by outline structure, I can leave the arrows off and simply drag and drop.

To go a step farther, I'd like to see the drag and drop order in the work view be completely separate from the one in the outline view. In the outline view, I'm working from _why_ I want to do this task. In the work view, I'm working from _when_ will I do this work.

     Bill

[Bryce Harrington (bryce)]

This is related to but separate from bug #497164.

497164 covers the case where tasks need to be ordered sequentially due to one task being dependent on another. For instance, "Buy gift", "Wrap gift", "Give present" all must be done in a strict order. This can be done in gtg currently by creating a "task ladder" using parent/child task relationships. Thus that bug is more of a UI presentation issue; it holds no implications for changes to gtg's internal task storage.

But this bug 345575 covers a slightly different case, which is that you have a set of tasks which don't need to be done sequentially, but you do want to visually think of them as a list in a particular order. For instance maybe you have "Buy gift for Alice", "Buy gift for Bob", "Buy gift for Charlie", "Bake cookies", "Chop firewood", "Decorate chrismas tree", and you wish to organize your tasks with the first three before the last three (since you need a bit more time to do the shopping and so on).

While you do want some ordering in this case, you *don't* want the laddered parent/child style of relationship as described by 497164, for a few reasons. First, parent/child ordering is quite buggy - but nevermind that. Second, when Work View is on, you can only see the first task, but it's likely the user would like to buy all three gifts at the same time when they go to the mall, so that's not so helpful. Third, there could also be an opportunity, such as her boyfriend offering to chop the firewood right now, that you'd like to be able to take care of now; but if you mark it done it marks done all the tasks before it in the laddered task list. Finally, it's likely you'd want to insert more tasks, such as "Buy gift for Donna", but the UI for inserting a task into a task ladder is rather cumbersome (and currently in trunk rather buggy).

Currently, I think child tags are not given any particular sort ordering under a parent. I guess in the taskeditor maybe it keeps track of the order they were initially entered in, but it's not guaranteed; I have found they can be reordered in some cases (like if you add a subtask from the browser). In any case, there really is no mechanism for the user to modify the ordering.

Thus, this bug is more geared around the idea of changing gtg's internal task storage to be more explicit in the way the tasks are ordered in a given parent. This does not imply any sort of dependency relationship or any other UI effect except that the tasks should have an explicit ordering that the user is able to influence.

I'd go further and suggest that the browser should also maintain this ordering when showing tasks in tree form (i.e. when Work View is turned off), if no other sorting scheme is in effect. This maintains consistency with the task editor and probably is least-surprise as far as user expectations go.

If this issue is solved, it may give a better solution to some of the more lightweight task ordering use cases (like given above) and thereby help mitigate the severity of bug 497164, such that people would only need to go that route when they *really* need strict ordering of tasks.

[peter pan (clarcraft)]

I think it is still a very essential feature to be able to move subtasks of the same hierarchical level within a parent task. Example: Parent task: "Preparations for party", subtask 1: "Buy food", subtask 2: "Clean the room". There is no dependency (parent/child relation) between the two subtasks. Now you decide to clean the room first: Within the GUI you will try to drag "Clean the room" and drop it above "Buy food". This won't work. This feature would make a very nice program even nicer!
thx for the software,

pete

[Jeff Fortin Tam (kiddo)]

Closing this ticket as we do not use LaunchPad anymore, see https://wiki.gnome.org/Apps/GTG to learn more about the current status of the project and to find the new location where our code and bug reports are hosted.

There is a ticket about this in the new bug tracker.