Show minimized edges

[keyserj]

Describe your issue

When I have a large diagram, I often create views with certain nodes hidden, so that certain aspects of the diagram can be focused on. But if a connecting node is hidden, that can create islands of nodes, losing some context where two nodes are actually connected through a node being hidden.

Solution you'd like

A toggle option to show minimized edges, like so (link to Topic in image):

rather than the current strategy, which just hides all the edges, creating islands:

Questions:

• should all hidden paths be shown, or just a max of one path (shortest) between the nodes?
  • multiple paths might not work well because they'd result in two edges between the same two nodes, which isn't yet possible in Ameliorate
  • using only one path would solve the islanding problem but still hides some contextual information
• what to do about paths that change directions? e.g. solution -has-> component, obstacle -obstacle-of-> component, with component hidden
  • in this case, due to the component relation, it seems ideal to show obstacle -obstacle-of-> solution; but in general this seems hard to figure out and probably just ok to let the obstacle be islanded or manually tied as obstacle of the solution
• how to deal with the situation where Problem-Solution edges are being intentionally hidden via the config?
  • right now, it seems that the logic would add a minimized edge between these
  • could minimized edges be calculated and added before the conditional hiding of problem-solution edges?

Alternatives you've considered

No response

Additional context

• ~this might eliminate the need for automatically creating edges for component relations~ edges are no longer auto created for component relations
  • and actually might be better, since without these, implied component edges wouldn't exist/need to be hidden in the first place
• this also would help with the question of "to show detriments above or below solutions?"
  • because a downside of showing detriments above is that, if detriments have a creates or created-by relation to benefits/effects, then they can't be easily visually separated from benefits/neutral effects; showing minimized edges would allow quickly using the "hide benefit/effect node types" functionality to visually focus on detriments, without losing the causal chain and creating a confusing island to the detriments

Technical ideas and questions

• probably just check (during layout) all pairs of displayed nodes for if there are no displayed paths but are hidden paths
  • if there are hidden paths, create an edge of type MinimizedEdge that has the path (list of edges?) between the nodes, and have the MinimizedEdge component show the labels of each hidden edge
• could use Dijkstra's shortest path algo, there's probably a library with that method somewhere

[prototyperspective]

In your example, isn't it preferable to have the connections/edges to "improve city's air quality" hidden? I think that would be the point of hiding that node and those nodes like "increase mass transit ridership" would also be connected to some other node(s) that are somehow connected to the subject – in that case, e.g. Solution:"Modal shift toward less polluting traffic" which would e.g. be connected to Problem:"City has bad air quality".

Moreover, I wonder whether selective hiding of specific nodes would be used much – instead one could have a way to filter out all nodes that one personally gave a low rating or for the purpose of focusing on one aspect/area have a view mode for some node one has clicked such as "Improve city's air quality" (btw I think this would be a node of type "Solution" not "Benefit" [relocating inhabitants, relocating as a personal solution, and getting personal air filter equipment would be arguably low-quality parallel solutions along with possible disputing that air quality is bad; "Improved air quality" may be a node of type Benefit but I thought only when the problem is not that which is addressed by it])

[keyserj]

isn't it preferable to have the connections/edges to "improve city's air quality" hidden?

In the example, "Benefit: reduce traffic congestion in NYC" is the node being hidden, so edges to that node would be hidden.

I could see a scenario where hiding "reduce traffic congestion" would desire to hide the rest of the benefits created in the branch beyond that hidden node, but the example was just trying to show a scenario where one might think an intermediate effect is less worth seeing than a root & final effect (increase mass transit ridership and improve city's air quality, respectively). (Note: sometimes intermediate effects can be more important than root/final effects too)

I wonder whether selective hiding of specific nodes would be used much

for the purpose of focusing on one aspect/area have a view mode for some node one has clicked

In my usage so far, I've wanted to show/hide specific sets of nodes to show some aspect of the Topic that doesn't align 1-1 with things I think are "most important". Often they're related in other ways, maybe like "polution-related nodes", "financial cost-related nodes", or something.

btw I think this would be a node of type "Solution" not "Benefit"

may be a node of type Benefit but I thought only when the problem is not that which is addressed by it

Benefits are specifically effects created by something. In theory "improve city's air quality" could be a (very ambiguous/vague) Solution, but by labeling it as a Benefit, I've implied that it's created by some root Solution (or sometimes, by some Problem). Note that Solution is intended to convey a plan that we could potentially take action to implement.

In this case, we're calling out that the root Solution "congestion pricing to get into Manhattan" (here's a link to the topic, I forgot to put that in here) creates the Benefit "increase mass transit ridership", which creates "reduce traffic congestion", which creates "improve city's air quality". Through this causal chain, we can see clearly the path for how the Solution is expected to produce the final effect "improve city's air quality".

[...] would be arguably low-quality parallel solutions along with possible disputing that air quality is bad

I would consider your example solutions as possible alternatives to the Solution "congestion pricing" for addressing "city has bad air quality". And disputing that air quality is bad is definitely something that should be possible in this Topic, probably via supports/critiques/questions/facts on the "city has bad air quality" Problem.