ForumsQuestionsSubsubtasks
Subsubtasks
| Author | Message |
|---|---|
|
Peter Scott |
Since it has been 5 years since I last brought it up, and over 10 years since it was first requested, I want to see whether there are any people left here still wanting more than one level of subtask. This is not a request for advanced project management tools like resource leveling or dependency tracking, neither is it needed only for business-level planning. Because I do GTD, I break things down to this sort of granularity:
Visit relatives for Christmas --------Get present for mother-in-law ----------------Shop for present ----------------Wrap present --------Do Christmas cards ----------------Take photo for cards ------------------------Decide on location/theme for card ------------------------Schedule photo Outlines are not the answer. They are a separate data repository with the semantics for arranging strings in a hierarchy and attaching a checked status to them. They're not tasks, they don't have attributes like start and due dates, they can't be filtered by status or tag, they can't be searched by folder or context, they can't be reassigned, they don't count towards the statistics, they can't have alarms attached, they can't have independent notes or files, and they do not convert to tasks when flattened. Outlines do not provide subsubtask functionality. I understand that this feature, while it has been on the todo list for over a decade, looks hard because of user interface issues with multiple levels of indentation. I would be able to do >95% of my cases with only two more levels of subtasks, so capping it there would suit me fine and maybe that would be workable. But for an approach that would sidestep the indentation issue, I have come up with the following. 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. |
|
Purveyor |
Hi Peter.
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. This is the same idea that you presented in 2013 as a "half-baked proposal". Has it been out of the oven this entire time? ;-)In traditional relational databases, each field contains one value per record. How will data be stored in your "Subtasks" field? Or are you talking about another kind of database? This message was edited Jun 22, 2018. |
|
Peter Scott |
For proper normalization, there would be an association table (task_id, subtask_id) with the pair of columns being the primary key. Query via join.
|
|
dmcguire |
What about being able to link tasks together (along with their subtasks)? Instead of having a sub-subtask, be able to create another task and link "up" to the now-parent task. Could add filters to the views to have linked tasks show up or not.
|
|
Peter Scott |
You still need a parent-child relationship so that when you mark the parent complete it completes any children.
|
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.