Hi!
The documentation says:
The
fillproperty can be:red,green,yellow,blueorgrey
Is there a deeper reason why status colors are limited to these? CSS names would be nice.
Cheers, Uwe
1 Like
Hi yes, we wanted them to be limited so that hopefully users could use and rely on them consistently, so in general red means error, green means good, etc. and also that people couldn’t theme them and change the colours which may cause confusion.
The editor evolved heavily during the last years. It has become a powerful means to see what's going on in a flow during development and also when flows run run.
I make copious use of debug nodes and their various status possibilities.
State is lagging behind here. Time to beef it up. red , green , yellow , blue and grey would still be possible, upward compatible, and well understood – but a wider choice would be appreciated, I think.
No violet , no orange. I really miss them. Sometimes I have (a) more than 5 states and (b) the color does not help to identify the state.
I did not look in the code but it should not be a big deal. If NR allows some 5 colors then it could easily allow those 140 standard colors.
What do you think, guys & gals?
Cheers, Uwe
I can’t easily tell the difference between ivory and corn silk, so no I think 140 is too many. I could maybe get behind a small extension, maybe adding cyan, magenta, black and white ?
The editor is not meant to be a dashboard
1 Like
That would help. Perhaps 16 easily distinguishable standard colors. For example Web colors - Wikipedia
Cheers, Uwe
No, it is not. But the editor is an invaluable tool to see what's going on during development and bug squashing.
Cheers, Uwe
I second that sentiment. That's probably also why, IMHO, more effort should be put into creating integrated introspection tooling beyond the debug node. But again, those efforts make the editor more of a "dashboard" - dashboard being something implicitly linked to the running system rather than being - as it is now - a static representation of what is happening on the server.
Along these lines, there is an idea of creating a running update of the context --> Streaming changes to context (NR5?) Which would also fall under the "dashboard" category.
I would love to be a fly on the wall and find out why all these "dashboard" features aren't being embraced. It makes Node-RED a far better tool for general purpose applications.
Ironically, for me, Node-RED isn't a "dashboard" nor "editor", it's just a fancy vector image editing tool. Unfortunately the shapes are limited to rectangles and lines connecting them but still just an image editing tool (built for the browser using jQuery).
The whole 'the editor is not a dashboard' is an outdated sentiment and not the view I take these days. It too readily dismisses the valid feedback around what the editor could do.
On the other hand, I can only embrace so many pieces of work at once. With a lack of other people actively getting involved, then it comes largely down to what order I pick things of the list.
I don't want this thread to spawn into a wider discussion, but for that one specifically, I have already outlined the hard technical problem that stands in the way; the underlying API doesn't support the sort of events needed to do that monitoring. Finding a way to update the API in way that doesn't break users with custom context stores is not trivial.
3 Likes
This is a really interesting point, because it raises the question "what is the purpose of dashboard".
In my world, the dashboard is for the end-user, and the editor is for the administrator. (End user in my case being family, but could be "operational staff" etc.)
In that case, would you really want the dashboard to be the place where you keep an eye on context data?
I think we need different terminology hence my phrasing:
"Dashboard" here is the wrong term. The "dashboard" is definitely a read-only, gauge-filled indication of the health of the overall system. The editor being implicitly linked to what is going on in the server is something completely different and definitely isn't a "dashboard".
So there are really three representations of NodeRED here: dashboard as in gauges, editor as in admin making system changes and "debugging"/"introspection" view of the running system in terms and related to the deployed flow, e.g. visual message tracing through the flow.
I would disagreed. The context data might (optionally) be visually represented in the dashboard as a gauge (also giving that data a semantic meaning). But in the editor (required) as your screenshot - i.e. context data is something important - potentially - to both views but should be displayed as is proper for the view and target audience. I.e. watching the context being modified directly in the editor is something an admin should understand, but it shouldn't be the view that a dashboard viewer should be shown.
….. indeed
I totally agree. I only had the topic in mind.
Probably so. But, out of necessity, I use it both as a dashboard and for debugging.
I use node.status a lot (color and text), on a few servers, used in a (quite) large factory.
The Christmas tree with all the colored lights is a small child next to my editor.
A few colors would help me (maximum 16, I'm not a painter)
