Explore other routing strategies / brainstorm arrow behavior

[nicpottier]

I feel like we are still struggling in making non trivial flows super understandable. Maybe I'm just not good at doing layout but it seems as soon as you have arrows heading back upwards things really start getting hard to understand.

Just opening this issues so we can discuss / track / brainstorm.

Possible solutions:

1. I am doing it wrong, stop doing it wrong. Totally open to that suggestion, but if that's the case how do we encourage the right way of doing it.
2. Some kind of exit merging when we go to the same place? Helps in the cases where you have lots of exits but are heading to one place. Doesn't help as much in cases where you have multiple node origins and different destinations.
3. Some kind of arrow merging / onramps? IE, when arrows are headed to a common destination, they somehow merge into a single path? Could simplify things and if done generally would work for the same node but different exit case above.
4. Try to route around nodes somehow? Maybe that is worse? But it does get difficult to reason about where things go when they pass behind nodes so maybe going around them would be better?
5. .. insert amazing idea here.

Example for context:

[ericnewcomer]

Ya, have thought a bunch on this. I think your example can be done better, but think that is besides the point. We can do better for them without trying to tell them to stop holding it wrong.

Here's how I'd lay that out..

But ya, that is pretty onerous and we can give them better tooling to make nicer flows. When it comes to this, one thing is I think it needs to be totally frictionless. ie, for it to be used, we'd want to do it as automagically as possible. So, ya, I tend to gravitate to something like the merging/onramp concept. I think the cleanest would be an onramp but with no offramp (because having gobs of arrows for things that'll never be routed separately sounds worth addressing as well). We could merge exits right after they come out (so you still have distinct exits with path counts). Then they merge right away and terminate as a single arrow (that can also be rerouted in bulk). To remove an exit from that route, you would need to delete the connection by clicking on the exit. This would allow you to route it somewhere else. If you route it back to the same exit again, it'll just remerge with the existing arrow. This merging would only occur if the origin was the same node.

Another thought is to specify if a category should branch or not in the node editor. Since exits and categories are disjointed, we can easily support having multiple categories go to a single exit. While this feels the cleanest and matches our spec/paradigm well, we'd be treating these as the same path, so counts would reflect that. That would be an accurate representation of what is happening, but users undoubtedly are interested in how many matched each category.

[nicpottier]

I agree with on-ramps with no off-ramps. I think that is nice in that it also addresses your point about maintaining the path counts which is definitely a really valuable thing that people like.

So ya, if I had my pick of things to play with that would be the first one.

[ericnewcomer]

Ya, I'd agree with that, it's where I'd like to start as well. Did play with that a bit a good while back and didn't find much joy, but am optimistic we can come up with a workable solution there. Sounds like a great feature for 6.0!

[rowanseymour]

File this one under experiments 🧪. Connector color is based on its destination...

[nicpottier]

Cute! I don't think it really helps in the original case I posted though, since the place things really start going wrong is most often when you have multiple origins headed to the same destination. But I like the experiment!

[nicpottier]

From a playing around perspective couldn't we see the effect of "cheater onramps" by basically having only a single attachment point for incoming nodes?