For the last month I've been working on an arrow toolkit for the web, called Quiver 🏹. It's exploring 3 problems: • What if visual connection could be declaratively expressed in HTML? • What if there was a tiny toolkit that enabled all kinds of connection/arrows to be built? • How do we break arrows out from spatial canvases and enable them to used on any website? Currently I'm prototyping some pre-built arrows/connection: curved arrows, orthogonal edges, Xanadu links and hyperedges. But the library is also explicitly designed to be extensible so you can use your own layout algorithms or designs. Part of the extensibility means the ability to easily animate objects along the arrow (for all of those dataflow VPLs out there 😜) or add arbitrary labels/annotations to arrows. Given that connection is probably one of the most commonly used relationships in visual programming systems, I'm curious if there are any other types of arrows or functionality you would find useful in your own projects? Its not published to NPM yet, but the repo is here.

Really awesome! A nice addition would be data-ports on the boxes and cubic bezier curves between these ports instead of arcs. A hack to make line-crossings more clearly would be drawing double lines.. where one of the two lines would be slightly thicker and have the same color as the background (I use that trick myself). Very nice to see the use of web-components! I believe that we finally will see a bigger use of these once react-19 is released.

@Maikel Thanks! > A nice addition would be data-ports on the boxes and cubic bezier curves between these ports instead of arcs. Ya the "data-port" edge with a cubic bezier curve is a type of arrow I've yet to dive into, thanks for confirming! > A hack to make line-crossings more clearly would be drawing double lines.. where one of the two lines would be slightly thicker and have the same color as the background (I use that trick myself). Do you have an example to share? would be curious to learn more!

You can check my project here : demo.codeflowcanvas.io .. you can load one of the examples via the top menubar (on desktop)

@Maikel Thanks, I see what you mean! Definitely has much better contrast! (Also it looks like you're in the canvas working group, maybe we've bumped into each other there?) @guitarvydas (I'm assuming you meant to respond in this thread!) 1. Totally agree! A current tension in this project is that these arrows operate independently of any specific layout algorithm. You can use it with browser layout algorithms (e.g. document flow, flexbox, grid, etc.) or your own absolutely positioned layout algorithm. This is because each arrow operates independent of each other, they look at their source and target elements and use some arrow algorithm to render and arrow in between. So it currently doesn't handle collision with other elements or intersections between arrows. Good in some cases, not desirable in others... some future work I want to explore is extending this approach to orchestrated element/arrow layouts! 2. Orthogonal edges are WIP (see video attached) 3. Edge bundling is another area of exploration I'd love to get to. I'm starting by implementing hyperedges. Maybe a naive edge bundler converts a set of independent arrows into a hyper edge, not sure yet? I'd also love to explore how interaction could aid in "busy diagrams",,, Things like hovering over a node to highlight associated arrows. Some times I think we focus too much on layout and not enough on progressive disclosure as diagrams grow.

@Christopher Shank yes I am in the OCWG and attended meetings 2 and 3

As a data point, here's a live diagram that I'm using to generate usable code. I drew this with draw.io (which sorely needs to be better when it comes to being a code editor): observations: The human gets the last say, auto-layout is a great tool as long as the human gets to say "nope, I want this to be displayed here" or something like that 90-degree connection lines (rounded corners, in this case) In some cases, too many lines make the diagram look "too busy" ("rule of 7"), in some cases it makes sense to bundle them together. In this case, I moved the boxes to where I wanted them, then painstakingly tweaked each arrow manually. In some cases, I reduced the diagram complexity by overlaying arrows on top of each other (poor man's "bundling").

Progress on s-curves and “data ports”

Is it extensible to other methods of rendering so I could use it in http://alltom.com/pages/ppl-lab-notebook/ if I’m using Three.js instead of HTML?

@alltom not exactly! Quiver is specifically designed to express connection/arrows in HTML. That said the arrow layout algorithms can be agnostic assuming you’re using a 2d canvas (guessing a 3d canvas would need to be different to account for the additional dimension) . Two of the packages I’m using are already separate NPM packages that you might be able to use: https://github.com/steveruizok/perfect-arrows https://github.com/dragonman225/curved-arrows

@Christopher Shank Lovely, thanks.

For what it's worth, some time ago I played around with similar things. It's not an npm, not animating something along the arrow path, also no labels (counting arc instead of line as minor detail?). https://gitlab.com/publishing-systems/experimental/-/tree/master/graph/html5-canvas/1/ and https://gitlab.com/publishing-systems/experimental/-/blob/master/graph-traversal-svg.xhtml (this one was made on request, as someone wanted to flip an org chart or something but ended up not wanting/needing such a thing). I guess it doesn't really matter that much if the rendering is a HTML5 Canvas, SVG or plain HTML via CSS. One time I found a neat module that generated railroad diagrams, that was nice too, I likely still have it somewhere (maybe it's still online at some place). Christopher Shank's first reply is pointing out that these things easily (naturally?) lead into the classic area of graph visualization, where there's a big potentially unsolved or unsolvable problem of computing good positioning, how to visualize big graphs well, not doing the force-directed spring thing, avoiding too many lines crossing, facing rendering + navigation issues, etc. In the good case, towards a draw.io/Kumu/MetaMaps.cc clone. Here's a short list of ideally libre-freely licensed graph visualization modules https://groupware-systems.org/skreutzer/graph_visualization_components.xhtml and why not add yours if it qualifies? Things like https://www.patreon.com/posts/2023-03-27-for-80661106 didn't make this list, because isn't really componentized, despite I made + then used a somewhat componentized version of it, but not updated. There's lots of these, even more if looking at proprietary ones. Things that draw lines and boxes. OK, for the 3 problems explored here, I have different answers for my own needs, so let's not go into it. Sometimes I wonder a little bit, if/as visual programming often utilizes these kinds of graph representations, if that's of help or essential to visual programming or visualization of programs, or it's more of a distraction and there could be something else that's more useful. Haven't decided/concluded - similar issue with text files of source code. It's not that either one makes the dealing with code/programs significantly better, just exchanges one representation with another?