[HN Gopher] How to draw S-curved arrows between boxes
___________________________________________________________________
How to draw S-curved arrows between boxes
Author : alex_stoddard
Score : 240 points
Date : 2021-12-22 17:11 UTC (5 hours ago)
(HTM) web link (dragonman225.js.org)
(TXT) w3m dump (dragonman225.js.org)
| nescioquid wrote:
| 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.
| kazinator wrote:
| Today (or twenty years ago, for that matter) I'd just output
| the data structure in graphviz syntax and throw it at the dot
| tool.
| pintxo wrote:
| If you want to add another level of complexity, add (non-
| overlapping) labels to your boxes and arrows ...
| [deleted]
| allenu wrote:
| I've had similar experiences on many projects. You start out
| thinking something is going to be super simple and you provide
| estimates that match your naive design and later find it'll
| take 2.5x-5x longer than you wanted. It's definitely humbling.
|
| Nowadays when I have new work that has a lot of unknowns, I try
| to jump in and create a proof of concept as quickly as I can,
| even if it requires a ton of hacks. I want to know right off
| the bat if there's something obvious that's going to make the
| task take much longer than I wanted.
| kazinator wrote:
| 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.
| klyrs wrote:
| 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_?
| javajosh wrote:
| _> I have Opinions_
|
| Good. Then fork the library and modify it to your liking,
| optionally republish.
|
| _> one box is fully within the other, and centered_
|
| This implies containment/stacking and wouldn't require an
| arrow. However, you could do worse than drawing 4 arrows from
| the edges of the surrounding rectangle.
| jedberg wrote:
| 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!
| anonymous532 wrote:
| 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.
| anamexis wrote:
| > 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.
| AceJohnny2 wrote:
| Not so weird. Here's a random example, from Wikipedia:
|
| https://en.wikipedia.org/wiki/Force-
| directed_graph_drawing#/...
| TobTobXX wrote:
| These are straight lines. Not sure you even _want_ Bezier
| curves in this context, striaght lines are probably clearer
| in these graphs with hundreds of connections.
| dragonwriter wrote:
| Is someone selling it as some kind of universal solution for
| production diagramming problems of all scales, or is this just
| unnecessary negativity?
| quickthrower2 wrote:
| 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.
| anonymous532 wrote:
| Yes, that is what I've noticed too. On medium/big projects
| macro-level(holistic) arrow functionality is far more
| important than having beautifully curved arrows from node A
| to node B. Solving that problem strangely resembles routing
| on a circuit board with buses, labels, colors, layers etc.
| kevin_thibedeau wrote:
| There is a section in Graphics Gems 3 that describes a
| layout system for an Atari ST DAW app.
| Minor49er wrote:
| 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.
| gunshowmo wrote:
| Fantastic article. This kind of insight into how people break
| down complicated problems into more manageable pieces is
| extremely valuable.
| emmanueloga_ wrote:
| 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/
| TacticalCoder wrote:
| That line-breaking link is really great, I enjoyed it a lot!
| However it barely scratches the surface: there's no good line-
| breaking without hyphenation. And then even once you have a
| great H & J algorithm (Hyphenation and Justification), you have
| the visual problem of "rivers" (be it text or print): a "river"
| behind when on one line you have the space between two words
| nearly matching another space between two words on the next
| line, then third line, etc.
|
| I don't know if modern typesetting software like InDesign do
| solve this automatically or not. The web certainly don't
| (although with CSS and the "shy" Unicode char you at least get
| some control on the 'H' part of "H & J"). Back in my
| typesetting days QuarkXPress had nothing to help with rivers:
| you had to detect them visually and then "fudge" the paragraph
| a bit (by forcing a line-break or an hyphenation).
|
| I always wondered: certainly if you start with a good H & J
| algorithm, it must be possible to try a few candidates and
| determine, programatically, which one has the least obvious
| rivers? Fascinating stuff IMHO.
|
| P.S: I also wonder if it's because algorithms for layout out
| paragraphs are _so_ bad on the web that justification is
| typically frowned upon on the Web? (it certainly rules king in
| printed books)
| vjeux wrote:
| Back in 2012 I made a series of blog posts about all the unique
| image algorithms I could find:
|
| - Facebook (that I designed):
| https://blog.vjeux.com/2012/image/image-layout-algorithm-fac...
|
| - Google Plus: https://blog.vjeux.com/2012/javascript/image-
| layout-algorith...
|
| - Google Plus, finding best breaks, which also explains fancy
| text layout algorithm:
| https://blog.vjeux.com/2014/image/google-plus-layout-find-be...
|
| - Lightbox: https://blog.vjeux.com/2012/javascript/image-
| layout-algorith...
|
| - Lightbox Android:
| https://blog.vjeux.com/2012/javascript/image-layout-algorith...
|
| - 500px: https://blog.vjeux.com/2012/javascript/image-layout-
| algorith...
|
| I hope that's useful!
| runeb wrote:
| Very interesting, thank you for this! Just a note that your
| demos do not seem to load images.
| melony wrote:
| One of the most difficult programming challenges I have
| encountered is calculating and displaying automatic drag and
| drop alignment guidelines/rulers (like those in Figma and
| PowerPoint that show up when you drag two element close to each
| other or near certain ratios) efficiently. They are not
| documented anywhere despite being a very common pattern. Most
| drag and drop libraries and framework don't have out of the box
| support for it as it requires deep low level integration.
___________________________________________________________________
(page generated 2021-12-22 23:00 UTC)