Figure out how to visually represent subtasks blocking multiple parents

[nekohayo]

One big design problem is how to visually represent a task being a child of more than one parent task.

Because in practice, in life and my daily use of tasks, there are many cases where I think one task is blocking multiple other independent tasks. For example, upgrading my web server might be blocking the creation of two different websites, etc. Apparently I'm not the only user facing this problem, whether in GTG or elsewhere (and in Asana for example, many people are asking for this)

Some technical/diagram reference:

• https://dba.stackexchange.com/questions/78266/how-to-represent-directed-graph-with-multiple-parents
• https://stackoverflow.com/questions/8640736/trees-graphs-how-to-represent-multiple-parents-and-children
• https://mindfusion.eu/blog/tree-with-nodes-that-have-multiple-parents/

Some knee-jerk ideas of potential approaches to represent this in the main window:

• Simply listing the task under each of the parent tasks (and providing some UI actions, in context menus and inside the task editor's toolbar, to be able to choose which tasks this task is a child/blocker of). This creates a longer treeview/visual duplication, but it's one way to do it.
• Same, but hiding/showing the child task dynamically, with some sort of animation, depending on scrolling or something?
• Showing the child under only one parent (which one? the most urgent one? the less-overloaded one? the most recently modified one?) and showing some sort of emoji icon (🔗? 🔱? ⥈? ⤚? ⤧? ⇋?) near the child task name to indicate that it is a multi-blocker, or using italic text for it?
• Showing the child on a separate row from its parents (but properly indented) and linked to each parents by an arrow from the parent, like what Planner does (if I recall correctly), this is mostly like doing a Gantt chart implementation. Actually, there could be a Gantt chart visualization mode for GTG, since it has all the info needed for that (including start/due dates)!
• Providing an alternate view mode canvas that users can toggle to show something like this (but more compact of course):

In the task editor of a child with multiple parents, the "Open parent" button could be a multi-function menubutton with a dropdown arrow on its right to allow adding more parent tasks... so:

• (Add Parent) - when there are no parents
• (Open Parent |▼) - when there is one or more parent; the left part opens the single parent or shows a menu if there is more than one parent, and the ▼lets you access "Add Parent".

Other ideas welcome!

[diegogangl]

I think before going all out on multiparents, we should figure out why we want them. If it's only to make a task block other tasks, we can solve this by adding a "blocked by" field and linking to those tasks. Then in the UI we could dim the label, show and icon with a link to the blocking task. This would avoid the whole need for a DAG and more complicated UI solutions.

I mean, the diagram looks sick but it feels like it would be more work to plan for the work than the actual work itself.

Actually, there could be a Gantt chart visualization mode for GTG, since it has all the info needed for that (including start/due dates)!

IIRC we had a plugin or something that did that. Or there was a PR, or something like that.

[agerhbour]

I think before going all out on multiparents, we should figure out why we want them. If it's only to make a task block other tasks, we can solve this by adding a "blocked by" field and linking to those tasks.

If I could give my two cents here. IMO, not having multiparents would make a hard line between what is a subtask and what is a blocker. It is a paradigm choice about how to use GTG. As an example, suppose I have a DIY project task, and a subtask is to go to the hardware store and buy hardware. However, my car has a flat tyre. Changing the car's tyre is a blocker to going to the hardware store, but it isn't a subtask of my DIY project.

This would avoid the whole need for a DAG and more complicated UI solutions.

Not sure about this, as you would still require a DAG to ensure there is no blocked by circular hell, and users would likely want to visualise the blocker dependency DAG.

In short, I don't think having a blocked by field solves the problem so much as it moves the problem over to blocked by. Thus it seems the best solution would be to have both multiparents with full DAG and blocked by field that also operates as a DAG structure.

[nekohayo]

Potentially a combination of #1027 + #1031 might help a bit with a portion of this, but indeed this does not tackle the definition of "blockers" (instead of "parent"), as @agerhbour rightfully pointed out. It's just an extra set of complementary tools to make it easier for users to navigate in something that remains very close to the current workflow and ontology.

Potentially relevant as a curiosity: Kanboard's ontology of internal task links
(I never really saw the point of going further than "blocks"/"blocked by" and "related", personally…)