GUI algorithms like these are not well documented anywhere (except, of course, all over the web and in source code! :-) ...

Would be nice to have a site, maybe a wiki, dedicated to this kind of thing.

Other interesting problems in this area:

* Layout algorithms

* Automatic assignment of keys for navigation (for nav w/o using a mouse)

* Popup menu prediction [1]

* Text breaking / paragraph layout [2]

* Etc, etc, etc ...

1: https://bjk5.com/post/44698559168/breaking-down-amazons-mega...

2: https://xxyxyz.org/line-breaking/

In cases when the boxes overlap, there are ways to choose an arrow which will not cross the boxes. But this is prevented by the constraint that the starting and ending points must be on the midpoint of a box edge. If the midpoint of the a given edge is occluded by a box, or occludes a box, then that edge is not considered, even though it is partially visible and has a viable point for the arrow.

E.g. if we could start an arrow in the middle of the small protruding "ledge" of the bottom box, we could do this:

    ,-------.
   :         :
   :         v
   : +----------------+
   : |                |
  +----------------+  |
  |                |--+
  |                |
  +----------------+

It's not written in stone that box-and-arrow diagrams must be connected by edge midpoints. That can't even work well any time you have multiple arrows emanating or terminating on the same edge.

Very good first iteration round, though.

I enjoyed reading this because it reminded me of a moment of hubris as junior developer. I was working with a complicated data structure I wanted to visualize, so I decided to write some quick code to basically read the data structure and output a graph as rectangles and lines connecting them.

I was chastened by the complexity of just drawing the lines between boxes so that they didn't overlap (as much as possible) and were drawn on facing sides (one of the later problems discussed in the article). I don't recall how I did it, but I do remember a sudden refresher on matrix multiplication.

It drove home how simple things can be more complicated than you might expect.

EDIT: also, I appreciated the way the article was written. No cruft.

The graphviz system [1], originally from at&t labs, has a program called "dot" that does this kind of thing very well, including routing the arrows around other boxes that may be in the way. It's been open sourced. It's also been ported to the web [2]

1: https://graphviz.org/

2: http://www.webgraphviz.com/?tab=map

We recently redid our landscaping, which included making the edge of the driveway and S curve. I thought my landscaper was pretty clever.

He took a flimsy pvc pipe, nailed it down at the beginning and end of the curve, and it bent into a perfect S curve that he then spray painted down to follow.

It’s amazing how physics and nature can solve these problems for you!

Such an innocent-sounding problem, but I've drawn tons of figures in inkscape, tikz and matplotlib and I swear, I'd never stop fidgeting with curved arrows if time was immaterial.

But of course, I have Opinions that would keep me from using this in practice. For example, my favorite style is similar to a half curly-bracket (or, taste depending, an integral symbol) -- two small semicircles connected by an axis-aligned line.

Edit: oh, and question from the peanut gallery... what if one box is fully within the other, and centered?

This reminds me of a project I worked on that had an interface with draggable boxes just like this. The library that we used rendered the boxes as divs while the arrows were drawn as SVGs. Apparently there was a bug on Internet Explorer 11 where CSS transforms being applied to SVGs would cause the browser to slow to a crawl, or crash entirely if too many were happening at once.

To get around it, I switched the line drawing function for IE11 so that it would draw two divs that would extend from the middle of each box and touch corners in the middle (basically figure 4 in the article), then style them with a curved border on the appropriate side. While not as elegant as what's shown here, it was convincing enough that nobody noticed any visual difference between it and the regular version.

Fantastic article. This kind of insight into how people break down complicated problems into more manageable pieces is extremely valuable.

This is a really great writeup. Whenever I try to draw diagrams using software tools, I always run into stuff like this and am disappointed with the tool's ability to help me out.

I've actually taken up hand-drawing diagrams lately and it's worked well. I get a lot of comments at work - "haha wow nice art!" (sarcasm) followed by "actually this is really easy to follow". I feel like it's both faster to draw and a more accurate representation of my mental model when I draw by hand.

But hey, if the diagramming tools were smart like in this post, maybe I'd go back to the tools for awhile ;)

The blog post is not bad, but as a graphics programmer I don't get why this one algorithm is made as a full NPM package. (Getting some left-pad vibes again...) The actual source code is about 200 lines (which can probably be shortened down to 50 if you try enough), why don't you just include it as a code snippet in that blog post for others to copy in their codebase? The code itself is pretty straightforward to understand, and you're probably going to make some little modifications to suit your needs.

The algorithm selects the arrow option with the shortest curve length, but I think the results would look better if it selected for the option with the least bends and inflection points.

Here's a specific example: https://imgur.com/a/1n2JiB3

I don't see why arrows must start at the middle of an edge. Sometimes multiple arrows from an edge look better if the end points are spaced apart (to emphasise the connectivity visually, for example). There are times when an arrow is positioned just on the inside of a corner, depending on what it is connected to and the angle of the arrow with respect to the edge.

In the final analysis, one should strive to get a visually balanced look, which takes into account placement, thickness of lines, density of information etc. There is no one-size fits all.

This looks like a nice result that can be useful in some cases, but it is limited to a single arrow. When you have more than one arrow, you get constraints like "minimize the number of crossings" and then "minimize total arrow line length". At this point, it becomes way more complicated.

Or you just draw stright lines and save yourself some trouble.

Because they are eaiser to stack without getting garbled!

http://move.rupy.se/file/logic.html

I think this post finally made something click for me: runtime generated SVG is incredibly powerful and I really need to add it to my toolbox.

slightly(?) related: https://www.zindlerb.com/improving-flowchart-editing-tools/

didn't gather a lot of discussion though...

It's cute and definitely a great way to "draw S-curved arrow between boxes", but, under the assumption of being built to be used within a real project with dozens or hundreds of overlapping connections, this, like many other node systems, fails to be usable unless you push the complexity somewhere else.

Is someone selling it as some kind of universal solution for production diagramming problems of all scales, or is this just unnecessary negativity?

> under the assumption of being built to be used within a real project with dozens or hundreds of overlapping connections

This is an odd assumption to make.

In that case the tool would need to lay out everything holistically but while it might do great arrow wise it could be useless for the user if they wanted the diagram a certain way for a reason.

but it's solving one part of the problem, and doing a good job at it. I've been making diagrams using graphviz, but setting the positions and edge curves manually, pulling the nodes and edges out of a list in excel

https://github.com/mathew-j-davis/boxesandarrows

I've been setting the 'waypoints' for more complex curves (curves with many bends) manually (typing the bezier numbers in by hand), while I try and figure out how I want them routed, you're right it's not easy figuring out rules for where edge should go, let alone implementing it

I think it depends on the use case and the organization/ordering of the boxes, which is not the focus of this library.

So for example, if the user is responsible for organizing the boxes and there is also a way to create custom arrows, this library can be used to suggest arrows, which might be good 95% of the time. That would be better than many of the tools I have used over the years.

However, if you want to generate a final diagram and can't guarantee, that the order of boxes doesn't allow for overlapping connections, this library is probably the wrong choice.

I don’t think the author is making any claims about the algorithm being able to handle more than the 2 box case. Why the negativity?