I just published a little app to draw graphs: https://git.sr.ht/~akkartik/snap.love
I've wanted something like this for a long time. Intended for small graphs where laying things out by hand is not too painful, and it's nice that things don't move around every time I make a change, as happens with graphviz (https://graphviz.org). The file format is also amenable to git; no long lines, and adding new nodes or edges doesn't reorder unrelated nodes and edges.
Immediately after sharing it, I notice that there's also a limit on the number of edges. Too many edges, and the dumb layout algorithm (connecting centroids of nodes) starts to creak.
04/22/2023, 3:27 AM
“t’s nice that things don’t move around every time I make a change’ == UX
suggestion: Drop code, say Python, into the boxes, hook the boxes up with 0D ==> Programming Language.
I guess the "export" function is "screenshot"? Which I think is perfectly fine for this type of application. Though I wish graphics platforms systematically had "save as SVG" for whatever is drawn in a window.
04/22/2023, 8:25 AM
Yeah, no reason it couldn't. Lines.love has SVG export, should be easy to port over.
04/22/2023, 9:28 AM
The difference between boxes drawn by normal humans and boxes drawn by programmers is decoupling.
Normal humans draw boxes that are asynchronous (e.g. boxes drawn on a whiteboard), programmers draw boxes that are synchronous (which leads to hating VPLs).
Rhetorical questions: Can Queues (LIFO) be created in Lua? Does Lua have anonymous functions (closures/whatever)? If so, then full decoupling (which I call 0D ATM) is easy. :-)
One more step: create 2 kinds of boxes: (1) code and (2) routing. Boxes of type 2 (Containers) are recursively defined - they can contain boxes of type 1 or type 2. In Lisp, type 1 boxes are called Atoms and type 2 boxes are called Lists. In my vocabulary, 1=Leaf, 2=Container.
04/22/2023, 5:46 PM
For https://nodysseus.io I went with autolayout only. To make that possible, it's got a tree structure - nodes have multiple inputs but only one output. This mimics some good programming practices too, so it works well.
# Auto Layout Is A UX Disaster
IMM, auto-layout results in disastrous UXs.
There are two kinds of code:
1. code for controlling machines, code that is machine-readable
2. code for communicating to human readers why code for controlling machines has been written the way it was - DI, Design Intent. Code that is human-readable.
When laying out code for DI - human consumption - spatial relationships matter. Do you want power-assist to help you lay out spatial relationships? Yes. Do you want power-assist to change the layout every time you make a change? No.
When laying out code for machine consumption, spatial relationships don’t matter. Current electronic machines (aka “computers”), work only with sequential relationships. Spatial layout doesn’t matter to machines. Auto-layout applied to this kind of code is just a waste of electrons.
Summary: layout only matters to human readers. Human readers grok things that are laid out spatially. Each time the layout changes, human readers need to expend brain-power to re-grok what’s being presented. Brain-power is bounded - users can burn brain power to think, or, they can burn brain power to re-grok what they’ve already grokked.
04/23/2023, 11:01 AM
@guitarvydas have you given nodysseus a go? Here's a tutorial showing a bit more of the autolayout behaviour.
I agree that spacial layout is only useful for human readers - and autolayout means that no spacial information is saved in the data structure of the graph.
In my experience, relayout when adding nodes is confusing if it cuts from layout A to layout B (like autolayout in touchdesigner or houdini). However, using d3-force for graph layout means that nodes can (somewhat) organically transition from layout A to layout B. The main layout problem I haven't solved yet is that between refreshes the graph can sometimes be laid out differently. It's usually fairly similar, especially if the graph stays the same as randomness is seeded by graph structure, but sometimes after editing a bunch and refreshing subtrees swap places. In those cases it takes a sec to orient to the different parts of the graph, but search is there to help. I'd argue the time/brain power spent regroking the layout is less than the time and brain power spent creating a meaningful layout manually (I and many other TD/Houdini/unity devs I know spent countless hours rearranging graphs where "power assist" autolayout hurt more than it helped), and for sure more human-centric than a large text file.
04/23/2023, 2:36 PM
There's nothing intrinsic to autolayout that requires layout to change every time you add/remove a node. As an obvious example, you could add the existing positions of all existing nodes as constraints to the solver. Perhaps this over constrains the problem, but I think it's under studied.