GTG

Bug #345575
Comment #6

Comment 6 for bug 345575

Revision history for this message

Bryce Harrington (bryce) wrote on 2010-08-08:

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.

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.