Really complete "nodes and wires" app builder: https://www.noodl.net/
I'm always curious how nodes and wires UIs choose to deal with control flow like looping... Looks like this one treats it as just another node: https://docs.noodl.net/#/nodes/data/for-each
It would be nice to see a visual gallery similar to Ivan Reese's codex (https://github.com/ivanreese/visual-programming-codex) that focuses specifically on comparing how concepts like looping are handled in each VPL.
Hey, this one is neat. It has a few UI conventions (like the nodes sort of snapping together like Scratch blocks) that I don't recall having seen in a node language before.
Also, J. Ryan Stinnett — Totally agreed on looping constructs being an especially interesting point of comparison. Would love to see someone (else, hah) do that analysis.
Bonus round: I just went to add this to the codex and.. well, look who it is! Thanks.
Haha, I have my own "new things to eventually do something with" queue over at https://github.com/malleable-systems/malleable.systems/issues, so I'm already in the mindset of adding things to their proper queue (in this case, your codex) when I hear about them. 🙂
I also like the idea of mixing nodes'n wires with snapping blocks à la Scratch, especially for document structure (DOM) like it is done here in Noodle, and like Mariano has done with his HTML learning with blocks some time ago.
the combination of legos and wires was an important part of our design for an efficient node editor before we decided to go in a different direction all together:
Very interesting mix!
I like the mix of vertical and horizontal snapping, it can bring some new expressiveness.
I was wondering about the use of tiling for classical sequencing and wires for control flow or data "stream". When I used Max/MSP it was great for audio etc., but very bad for executing a series of operations, the wires add clutter. And I thought that tiling boxes might be the solution.
Too bad you didn't choose that way Chris Granger, I really like it!
yeah, after a bunch of experiments and trying to understand what was actually going on fundamentally we arrived at some useful principles to work from. If you compare the top left to the bottom right, there’s a huge difference in visual clutter.
One of the big things we realized about most node/wire systems is that it’s actually pretty hard to separate the “main idea” from all the details. This vertical/horizontal split was our attempt at making that be inherent to the structure of the diagram you ended up with. The “what” flows top to bottom and the details flow left to right. This means if you read just the “spine” of the diagram, you’ve got a good idea of what’s going on.
Another thing was making sure that the locuses of action were clear and easily accessed rather than being effectively spread everywhere (which makes a keyboard-heavy flow difficult to imagine)
From my notes on it:
The “puzzle box” is a bit like a structure of spreadsheet cells, except rather than an infinite grid, only cells directly connected to an existing cell are available. We differentiate the flow of power and flow of values, by placing slots for the former on the vertical axis, while data slots go on the horizontal axis. By default, cells snap into each other like a block-based editor, but can be pulled apart, revealing a wire when more space is necessary or flow is better demonstrated. Cells usually contain textual “formulas,” which preserves the density of text and makes it easy to edit complex expressions with few actions. They can also have complex domain representations (e.g. the truth table above) that are plugged into and used directly. Using this feels more like excel than any of the previous editors mentioned. There are clear places for action - empty or existing cells - that you navigate to and start typing in.
The puzzle box takes the best parts of text, nodes, and blocks, while offsetting the downsides of each: * We leverage the density and familiarity of text in each cell * By using wires for branching and complex control, we can maintain the ability to easily understand the flow of the behavior (offsetting the 1D of text). Splitting control out vertically, allows you to quickly “read the spine” and get the main idea of what’s going to happen. * With the connected cells, we get the structure of block-based editors and can make it clear where actions can be performed. This also enables a primarily locate and act flow. * Rather than pure text, we can progressively disclose the internals of the cells, including showing slots only when they’re part of the flow
By default, cells snap into each other like a block-based editor, but can be pulled apart, revealing a wire
Smart.
I really like all this. Especially the fact that there are several ways to visually assemble and organize things, that are not necessarily exclusive (snapped boxes can be drag and become nodes'n wires) but this gives a palette of representations that you can pick from to make your code the more expressive. It is really in that kind of direction I want to work on!
Yeah, go for it! This was the best we could come up with for this direction after a good bit of trying. I still believe it’d make a badass node editor. 🙂
I still believe it’d make a badass node editor.
Well someone here's gotta do it!
Another thing we teased apart is that there’s a difference between the micro and macro flows of using such an editor and we found almost every system seemed to treat them the same, which is a significant mistake. These node assemblies are all about the micro flow, but how you view/navigate/locate/act on the whole system is something else entirely. It actually has a lot of parallels with micro/macro in RTS games.
I would push back on "node assemblies are all about the micro flow" — your nodes themselves contain things, and a lot of the friction with existing VPLs comes down to (IMO) a misalignment between what's happening within each node vs. what's happening around it. I'd propose: "node assemblies are all about medium-scale flow". That is to say, I agree with your point so much that I'd go even further: there are at least 3 distinct scales of concern, and only one of which (the middle one) is attended to by current node-wire tools.
It was on my plan to work on this kind of stuff, i.e. mixing visual representations. I have been busy with some other stuff, but this discussion and your screenshots made me want to work on it sooner!
a misalignment between what’s happening within each node vs. what’s happening around itwe had a fairly nice way of unifying nodes and assemblies, such that that was less of a distinction (it also resolved several other problems these systems have, like dealing with state transition rather than dataflow)
More on the fun/cool side, inspired by Ivan Reese’s lunchbox sessions, we wanted to make it so that anything can be replaced with it’s representation, but retain its editing semantics. This means, for example, you could replace the wires with pipes and nodes with engine parts, but connecting them still meant semantically connecting them under the covers. 🙂 There’s a little bit of that in the images above where the picture of mario jumping is the representation of the jump node.
It is another idea I want to dig: having the ability to change the representation of "programming semantic", again to choose the one that is the more expressive.
Like in your examples for if/then where there are several ways to represent it.
Chris Granger: Your wires-and-snapping designs are great, and I'm glad they've sparked so much good discussion. But I want to call attention to something interesting about how Noodl in particular is using snapping...
It looks like Noodl uses snapping in one place: building layout trees for their views. Here's an example:
This is interesting to me, because a layout tree is a fundamentally different visual formalism from a nodes-and-wires graph. (I mean, I guess you could build a hierarchical layout with nodes-and-wires, but it wouldn't make many people happy.) But it looks like Noodl does a good job of fluidly integrating the nodes-and-wires formalism with a tree formalism.
It reads well:
- "Here is the part of the tree that triggers state changes when clicked!"
- "Here are the parts of the tree that change appearance when the state changes!"
Arguably, it would be even better if the "States" node could connect directly to the actual components in the live preview, rather than just the abstract representations thereof. This would give it a look kind of like that https://www.youtube.com/watch?v=Gy5m091fOTU, where a node graph connects abstract nodes to concrete objects:
In summary: I'm excited about replacing noodles in node-graph systems with structured snapping, as Chris Granger's designs show, AND I'm excited about extending node-graph systems to include different visual formalisms, as I believe Noodl is doing!
