ForumsQuestionsSub-subtasks
Sub-subtasks
| Author | Message |
|---|---|
|
Salgud |
Posted by DSM:
If you had functionality that allowed you to completely deal with subtasks, but not display them as subtasks (ie. indents) in the Toodledo task table, could you live with using Outlines for the display of your task hierarchy? What I suggested elsewhere is adding a scripting capability to Toodledo that would allow a script associated with a task to query the status of another task and set the current task's status. Something like: If TaskA.status == COMPLETE && TaskB.status == COMPLETE then TaskC.status = NEXTACTION Using this, you could easily implement subtasks to any number of levels as well as implement sibling tasks, dependencies, and so on. I hate to split hairs, but for consistency in this conversation, what you have illustrated is not a sub-subtask, but a dependency. |
|
DSM_2 |
Hmmm. Yes, you're right. Subtasks could either be that two tasks are simply related as parent/child or that the parent task should be set to COMPLETE once all the children are COMPLETE. The second approach could be done as a script say:
if TaskB.status == ACTIVE || TaskC.status == ACTIVE then TaskA.status = ACTIVE if TaskB.status == COMPLETE && TaskC.status == COMPLETE then TaskA.status = COMPLETE or something similar... |
|
Salgud |
I guess I would encourage the TD team to do a lot of other enhancements first (practically everything), as I haven't found it a huge waste of my time clicking to complete a parent task when all the subtasks are completed. YMMV.
|
|
Peter Scott |
Posted by DSM:
Interesting point. How about this? The problem with sub...tasks that the Toodledo developers seem to be having is display. What if they implemented a field similar to the Tag field called TaskIDs. Then they would have a GUI that would allow one to pick other tasks to add to the current task. The user could create a hierarchy or a DAG or a dependency list or combination as he sees fit. For you, moving a hierarchy from one parent to another would simply be adding the new parent to and removing the old parent from the TaskIDs list. This reduces the functionality from the scripting approach I suggested above in that they'd either have to set some assumption on what happens when a dependent task is COMPLETED or leave that to the user (similar to what they have now), but it stays close to the current Toodledo interface. After that, using the Toodledo API, someone might be able to come up with a display program (like a mindmap) that would visualize the graph of the tasks. This probably wouldn't be that hard to do with some scripting and the open-source GraphViz/InstaViz program. Yes, I could live without the indented display if each task had a clickable list of subtasks and I could drag one to onto another to make it a subtask. That would, however, present significant problems for Jake to reconcile with the existing one level of subtask interface and how to make a task link clickable in the mobile version. I know you were only suggesting task ids in the list, but it's no use unless you can rapidly navigate to the corresponding task. |
|
Peter Scott |
Here is a half-baked proposal. Pretend for a moment that the current subtask functionality doesn't exist. Here's the idea: Outfit every task with a field called Subtasks, which is a list of zero or more IDs of child tasks. When displaying this field in any view, it renders as a list of the subtask titles, one per line, each of which can be clicked/tapped to replace the current task view with the child task. Each task also has a field called parent task, which is populated with zero or one IDs, likewise clickable/tappable.
Interfaces may supply the means to populate those fields. When adding a subtask to a task, the server will throw an exception if any subtask of that subtask is the task it is being added to, or if the subtasks's parent task field is nonempty. When adding a parent to a task, the server will throw an exception if any parent of that parent is the task it is being added to. When a task is added to a subtask field, the server will populate the parent field of that task with the ID of the task it is being added to. When a task is added to a parent field, the ID of the task is added to the subtask list of the task being added. Interfaces may implement the above functionality by drag and drop, each operation according to a different target. Interfaces should provide a means to reorder IDs in a subtask list. Completing a task causes all the children (recursively) to be marked as completed. Okay, so far not much different from today other than the arbitrary number of levels. Here's the consequences: Subtasks are displayed only in the list field. Not indented underneath the parent. Dragging a task will therefore not have to drag children with it. The little "is a parent"/"is a child" icon goes away. The "repeat with parent" choice for task reoccurrence should probably be removed. I have a suspicion that it already has problems and it would have more. I don't think it's easy enough to tell what it's behavior should be. I don't think there is any other functionality that would have to be removed. Obviously it would be *theoretically* possible to display the trees and drag them around, but in practice there could be insurmountable headaches with deep trees. Instead, develop a tool designed just to show a task tree, somewhat like the outline view. Not that you have to. I think this is workable. I don't know whether you could do it without too many people howling about losing the indented display, or whether you could reasonably make the behavior user-selectable with the current behavior being the other option. I do think this is the way to go - get the model right first, make the interfaces whizzier later on instead of letting user interface limitations dictate the model. Comments? |
|
DSM_2 |
Interesting, but I would prefer to have dependent tasks over subtasks. However, I think both can be achieved by changing your proposed SubTasks field into a DependentTasks field and just not implementing the recursive action or, perhaps, two fields -- SubTasks and DependentTasks. The SubTasks field would keep the functionality you describe above while the DependTasks would have similar functionality. The two fields would be to implement the following two rules:
1. If all SubTasks are COMPLETE, then set the current task to COMPLETE. (You could add in your rule of marking all subtasks as COMPLETE if the current task is set to COMPLETE.) 2. If all DependentTasks are COMPLETE, then set the current task to NEXTACTION. I think that would cover all of the standard use cases. Some people might not want the rules, so the implementation of the rules could be a preference setting for each user. In the long run, however, I think the scripting approach would be more flexible. For instance, on top of the above rules, you could check the date and implement a lag time between when a dependency is COMPLETE and the current task starts up. Or you could check other non-task fields -- you get the idea... |
|
Peter Scott |
Can we contribute in any way to making subsubtasks happen in Toodledo? What is their position on open sourcing the code?
|
|
User |
Just adding a note to say I would pay additional for sub subtasks.
|
|
tobiasdiez |
In my opinion, the best visualization of dependent task would be in form of a mindmap.
As there are many javascript-mindmapping plugins, I think the hardest part is actually to map the dependencies correctly and add the logic (i.e. display task only if not dependent on other tasks). Would be a nice addition! |
You cannot reply yet
U Back to topic home
R Post a reply
Skip to Page: 1 2
To participate in these forums, you must be signed in.