Visual clutter in flows

I love Node Red but the visual clutter in flows with lots of nodes can border on impossible to debug when there's a problem due to the sheer tonnage of wires. My idea (and no clue if this is hard to implement or not): highlight the operative wires in, say, orange so at a glance I can see exactly which nodes NR is connecting to. Right now, all you can do is attach a bunch of debug nodes to each of the nodes and try to figure out where things are going wrong. To be able to simply visually see what's going on - like this circuit GIF but imagine it with NR nodes and wires - would make creating and debugging flows enormously easier I think:

7qbG

Can you post an example image of one of your flows, perhaps we can give some pointers.
Your suggestion won't work in practice, due to the sheer number of messages that can go "through" the wires (let alone the render performance)

I don't need help debugging my flows. I've been using NR for years and the visual clutter in flows with a large number of switch and/or change nodes makes it very difficult to debug without constantly adding then removing debug nodes to see where the error is, and I was looking for a way to see visually what NR is "thinking" in order to correct it.

Perhaps rather than a real-time circuit diagram, there could be a snapshot option which would present a visualization of a moment in time which would effectively amount to the same thing.

All I'm saying is detaching debug nodes is really tedious plus still, with flows with lots of switch and change nodes, it's still really difficult to find one mistake in all the clutter. I know there's that NR Debugger node which is a bit of an improvement but still, what would be best IMHO is a way to simply visually wire-trace and NR flow because you could almost instantly see your error that way.

Perhaps my solution is impossible to implement, but as a fairly longtime user who's done a lot with NR in terms of home automation, the current way (say 50 nodes, a millions gray wires all bunching together and crossing each other, etc.) makes it really difficult to find and correct errors.

My point was not in helping to debug, but helping in the flow setup, 50 nodes don’t have to end up with a “million” wires (better yet: shouldn’t)

2 Likes

Spot on.

I think this is my most complex discrete flow:


And actually, I think the pattern is pretty clear. Though maybe that's because it was likely the 10th attempt over a decade and I'm now so used to it. :grinning:

1 Like

I have a number of simple flows though honestly even there visually debugging would be way faster than manually doing so. And I have a few like this one:

My immediate suggestion would be to compare yours against mine. Note the number and placement of link nodes and the use of groups. These are key to making simple-to-follow flow layouts.

You are also triggering my OCD by not placing nodes on a neat grid! :grinning: That may seem like a joke but remember that your brain has to visually process all of that, having even, level, balanced layouts reduces the cognative load.

I am afraid it's possible to create impenetrable code in Node-red just as it is in C or python.

When a flow gets out of hand, go and reorganise it.
Put connected nodes close together and assemble them into groups.
Use junctions to minimise crossing wires.
Connect far apart groups with link nodes.
Delete all the debug nodes and put back only as you need them.
Use meaningful node names and comment nodes,
etc.

I make the wires narrower and with better contrast using CSS.

My flows work for me and they're as minimal as they can be for what they're doing. I'm suggesting that, instead of me contorting my flows around the visual clutter created by NR, that perhaps there's a way for NR to address it. NR allows for flows as complex and large as mine but doesn't have a UI that scales for such large flows - it borders on impossible to select the correct wire for example if trying to delete it.

I'm saying NR, as with the actual analog wires it's mimicking (I mean I think we've all seen cable chaos coming out of desktop computers or servers), gets very messy the more wires there are, and I'm suggesting there may be a way to mitigate that visually.

This can't be reduced further due to what the flow is doing. The problem with the grid is it's a tradeoff because as you can probably tell, I had to zoom out several levels just to take the screenshot meaning if I want my flow to be readable (zoomed normally) I need to minimize spacing between nodes so more can fit on the screen. Again, NR allows for large complex flows but the UI really doesn't.

No offence intended but I think there is a way. Clean up your coding style.

But who knows, your flows may be unusually and irreducibly complex. Maybe that's why @bakman2 asked to see an example.

Yeah great answer.

Well, I think that you first need to acknowledge that it isn't Node-RED that "creates" the clutter. As several of us have said, there are certainly ways to minimise the visual clutter and they have nothing to do with minimising the flows, only simplifying the visual layout and reducing the mental overheads involved with visually processing them. The logic need not change at all.

Adding additional visual elements to highlight active flows would not reduce the cognitive load but almost certainly increase it.

Lots of us have flows easily as complex as yours, we simply may not lay them out the same way.

It does, just not the way you are using it.

Absolutely there is, but your approach is not the only one. Just like a well done server room is an art-form in itself, so complex flows in any "language" whether flow-based languages or circuit boards are similarly works of creative art. The more complex a visual layout, the harder it is to get it right - just like painting or drawing. Or, indeed, in my professional world, complex architecture diagrams.

But, just as in other forms of visual art, there are tricks to making things work. Visual spaghetti is never appealing as you've already intimated.

I'm not suggesting you reduce the complexity of your flows. I'm suggesting laying them out differently.

This is exactly the same, as jbudd indicated, as text-based programming languages. A monolithic morass of code is equally impenetrable. Which is why all experienced programmers learn to break the code down into components using functions, libraries and modules. Otherwise, just like your complex visual layouts, the code becomes almost impossible to debug.

1 Like

Here we see at least 19 duplicated nodes (i forgot a couple i see):

Duplication means redundant. ie. could your flow perhaps start with 'home or away' and build from there for example.

The wires can be replaced by link nodes.

Again, I don't help with my flows. They're the way the are for a reason and it's not because I didn't think through other options; it's because this is how it has to be to do what the flow needs to do for my life. I'm not sure how my feature request to reduce visual clutter became a critique of how I use NR.

We are trying help you here.

Good luck with your endeavour, the source code is on github, you are free to animate it to your liking.

It is the way you are using NR that is causing the clutter. Exactly the same functionality can be produced with much less clutter.

But to return to your original request:

What exactly do you mean by 'which nodes NR is connecting to`?

One feature that Node-RED does already provide that may help would be the link nodes.

They are useful when you want to wire together two distant nodes with having the visual 'noise' of a permanently visible wire.

The link nodes wires are only visible when the link node is selected.

That is an option you could explore today, regardless of whatever other enhancements may come in the future.

Another existing feature is that if you ctrl-click on a node, it will select all nodes it is connected to.. and if I remember correctly select the links so they are also highlighted. I'm away from my laptop so can't give a precise demo, but again, another existing feature that might offer some assistance.

Something like the green line below, as in "the green line is the node to node jumps in the flow right now".