if the image is over the node, why not make the image clickable if possible) which would open the node configuration
1 Like
Yes, as previously mentioned, there has to be an ability to open the config. And the ability to easily show/hide the extra display.
A flag in the config that lets you decide whether the default is shown or hidden would be very helpful.
1 Like
Although this looks very nice, I am wondering if this isn't too much different looking from normal nodes? With your rectangular shape it was still pretty visible that it was a node, just a fancy one. But now the middle one looks more like a very elegant junction instead of a node 
Not sure whether people will immediately recognize it as a node? But again, it looks nice.
So I am wondering - if this ever would become possible - if it is better to restrict the visualization to a rectangular shape or not?
Blimey!
What happened to 'The editor is not a dashboard' 
Personally, i'm quite strict in that practice and not using the editor for any form of monitoring, that's not to say it can be useful of course given the right use case.
But this thread looks fun, and I like designing.
To me, the gauges look to 'disconnected' from the node that represents them.
IMO, I think the gauge should be apart of the node its self
Something like below.
EDIT
And yes!
I have just created a tumble dryer in Node RED 
2 Likes
I'm counting to ten.... 
1 Like
Please don't keep repeating that. Never awake sleeping dogs
Well at least you managed to create a tumble dryer node. I mean that at least you see immediately it is a node. Perhaps that might be easier for people to get familiar with this kind of nodes, because the difference from normal nodes is not that big...
And when you click on the top area (i.e. icon and label) the config screen will appear like normal, but when you click in the visualization area the visualization can respond to that in some way.
About the inputs and outputs of your node. You draw them at the top, while @johnebgood placed them in the center:
Not sure if that was a conscious choice, or you just forgot about it.
But it might have an advantage to attach the wires at the top of the node. When you hide the visualization (via the node's config screen) then the wires don't change if they are attached at the top. If you have used e.g. junctions to nicely route your wires, then that routing won't be changed by hiding or showing the visualization...
2 Likes
Oh this was just a swag change to the height via CSS to fit the gauge (shamefully lifted from a web image search).
Its actually the function node 
Yes, having the pins centered would make for better uniformity
EDIT
Thinking about this in more detail (sorry if itās already been discussed, have not gone through the thread in detail)
But having an area to display runtime updatable content seem intriguing, not just for gauges as an example.
Ah yes, thanks for the tip.
The node-red-contrib-image-output node would look this way like this:
Or
Personally I like the latter one, because - as explained above - the wires keep untouched when you hide the vizualization.
BTW not sure but perhaps there is an extra advantage of such a visualization inside/on-top-of the node: because it 'might' also still work fine with the current auto-layout algorithms. Because those algorithms take into account the area of the node.
I've thought a lot about the "editor is not a dashboard" idea over the past 12~18 months and I think it makes a lot of sense, but I also disagree with it because of the same factory paradigm as johnebgood. Were NodeRED state-based rather than message-based, inline UI would be a no-brainer. For NR though, a button next to each nodes "Enabled" toggle (at the bottom of the sidebar panel) for "Show Inline UI" could satisfy the best of both worlds: it'd only do something if the node developer has configured inline UI (which could be done in much the same way the current UI and help text is at the moment), it wouldn't affect the myriad of existing nodes that don't have any inline UI, and the visual clusterf*ck of lots of disparate inline components in the editor is avoided by default because the user would explicitly have to enable each one.
I can see an issue with some node developers preferring inline UI to the sidebar, which could take away choice for the user. Perhaps data-nr-inline attributes on the HTML could be used to ensure components that appear inline also appear in the sidebar?
I think, at a simple level, its nice to be able to see your code and view a "dashboard" on the same web-page
I come from Scratch/Snap! and that's exactly what we do
But, I genreally just do home IoT with NodeRED and the debugger and node status do most of what I need/want
I can see it would be nice to see a fancy gauge on the editor but nice doesn't cut it for me to go against long held NR philosophy - You've got to push back against the waves 
Maybe what is needed is the ability to view a dashboard instead/as well as the debugger?
[edit]In Snap! we can vary the size of the stage on the right depending on what's more important - seeing the code or seeing some results from it
Just my thoughts
Yes I totally agree that by default the nodes should look like today, and the user explicit needs to activate the inline visualization. That way the flow editor 'by default' will still be not a dashboard. Unless the user really likes his flow editor to become a dashboard...
1 Like
The main objection is ā do you really want to allow users access to the editor/admin side of the application. While Node-RED is indeed often used in āsimpleā home automation tasks, if it is used in ā productionā however simple that may be, if you require access to the editor in order to see what is happening then that person has full access to the application. Even in a home environment the possibility for inexperienced users to mess things up is huge. I can see the utility for debug and testing, but it should not be the default ui/dashboard for users
6 Likes
For the past 8 years, I've dissed the comments "the editor is not a dashboard" at every opportunity, but now I'm beginning to eat my words....
I think this becomes especially important for the use cases where flows are operating only as a backend (no dashboards needed). One could argue it's actually a bit backwards to default on text-based debugging in a visual programming environment and I'd personally love to have discrete visuals without the complexity/clutter of setting up nodes only for a quick dashboard or ui-builder frontend that only flow maintainers will ever see. Beyond backend-only flows, the idea of "locations" for UI components in visual programming interests me, such that users and/or node developers would configure where components are displayed... inline, sidebar, or frontend (dashboard) for example. I don't know if this concept is necessarily a good fit for NR, but packaging UI components with nodes could make "flow-to-feedback" workflows easier to create
1 Like
Paul,
So I assume you don't like the proposals being made here?
I have a lot of interest in this discussion, because currently some users - like me - already use this kind of nodes, but we have to find a lot of workarounds to get it done. Would simply like to have a more easy a standard way to do it.
And people that don't like it have the advantage that it would be disabled by default, so they can keep having a simple classic flow editor. So from their point of view, nothing changes. And from our point of view, a lot would change.
And to be honest. It isn't only me and a couple of weirdos that like a bit of visualization stuff in their flow editor. When you look at the npm download statistics of the node-red-contrib-image-output node, then we see that there were 57239 downloads in the last 365 days. I think that number speaks for itself...
Not that impressive Bart...
I got 32,875 from node-red-contrib-simpletime, and I'm not even a developer...
I do like some feedback in the editor, but should be discreetly, like node.status etc.
vs 1.3 million for node-red and over 100 million on docker . As I said, while I canāt see a mainstream use case I certainly can see utility for debugging, so Iām not totally against the idea, just not sure what is stopping people implementing today. The examples given so far seem within reach of decent developers.
I agree with disallowing consumer users access to the editor/admin only for the sake of seeing some UI. This and the visual simplicity of the current node appearance are great reasons to keep them separated. However, the question I am now thinking about is how best to enable pre-packaged visuals/UI with nodes. I can see a few ways forward:
- Allow inline UI on nodes, but only if it is turned off by default and enabled per node instance per flow. This would only be for flow developers and maintainers, who could toggle which node instances show inline UI.
- Allow UI/visuals in the editor sidebar, perhaps as a new
tab-linknext to other buttons. This would bring together UI 'widgets' from multiple node instances into one location without cluttering the flow grid. Similar in appearance to the Scratch/Snap screenshot from cymplecy. This would only be for flow developers and maintainers, who could toggle which node instances appear here. - Effectively allowing custom dashboard-like functionality from all nodes, such that they can expose their own UI to be used in the same way as the current
button,slider,gauge, etc. In the editor, flow developers could then configure which controls and data are exposed to the dashboard through either a newnode-red-dashboardnode or the sidebar UI.
As I've written this, 2. and 3. seem like the best options. For a quick fix, 2. could probably be done by writing by a package that adds a /ui iframe into the sidebar tab links. 3. would require/benefit from integration with uibuilder or node-red-dashboard in order to gain momentum. In any case, I know node-red-dashboard is being re-written, so discussion along this route may be best kept until the new version is seen...
Which, of course, you can do if using a decent browser.
Edge lets you have a "split screen" view as do one or two other browsers I think. I sometimes use this feature when making a uibuilder video.
