I suggest to do something about the fact that when you connect two symbols in such a way that there already are symbols in between, you don’t “see” the new sequence flow in between them. Example: two XOR gateways, in between a task, you want a second sequence flow connecting the gateways and circumventing the task. Instead of adding drawing heuristics, I suggest to support the user to “see” the overlapping flows and be able to highlight the correct one. A solution could be that such a flow (one that overlaps other symbols!) remains the “marked/highlighted” symbol directly after it has been drawn. On top of that I would suggest, to show the yellow bar (the one for parallel “moves/shifts”!) of such flows (or all flows?) ALWAYS when the flow is marked/highlighted and not just when hovering over the right position. For less experienced users it can be VERY hard to track the right spot and “grab” such a flow. In certain situations even experienced users have a hard time. 
I thinks always showing the parallel move markers could solve a couple of these issues.
We could give it a try, some day maybe.
Can’t we just have a better automatic layout for many connections from A to B, so that they are clearly visible to start with ?
Can’t we just have a better automatic layout for many connections from A to B, so that they are clearly visible to start with ?
Could you provide a visual example? What would be a case for many connections from A to B? what would be the preferred way of layouting these.
I attached the following gif:
The idea is when I create two or more consecutive connections between two nodes I don’t want them to overlap, because i don’t how many of them there are anymore. You can make the layout engine calculate slightly different positions so that two ore more connections don’t overlap entirely(like i did manually in the gif).
Is this something you’d ever want to model?
It’s possible that you will not be too often in a case like this. We have an old workflow model where this is allowed, and we received some complains that the connections can overlap. We asked again now when will this actually happen and it seems it’s just a rare corner case for our particular workflow that shouldn’t happen anyway.
Thanks for your reply.
Thanks for clarifying.
Technically you could build things as you described. In general though we try to focus our attention towards solid modeling that does not allow these kinds of models to happen in the first place. I’m sure we got a lot of room for improvement there, too.