Dear All,
I don't know if I'm the only one but for most of my contrib nodes I spend more time building the config UI than for the core functionality. People get very creative (my self included) building these but in the end a config object with a finite amount of possibilities is the result.
I'm certainly not the first one who was thinking if it could be a solution for many nodes to have a editable properties bar. The base is already there:
But it would be nice if it could be made editable.
Primitive properties are easy if the type is fixed. If not something like typedInput could be used.
Objects will become collapsible groups, Arrays can be solved with an "editable list", config nodes definition could show as drop down with ... and + and so on - I hope you get what I'm up to.
The node creator only has to define parameters around the values like default, type, min and max value, options, validators, placeholders, tooltip, read only or hidden flags, order, for arrays: sort-able, erasable, ....
A single click on a node will show the config in the properties bar. Selecting many nodes of the same type / module could make it possible to edit them all together. A double click on a node should still open the config drawer either showing the same editor (using the bigger real estate for more comfort) or a custom UI with more fancy features.
Good and bad examples of these properties bars are all over the place.
The transition could be seamless. If a nodes provide the necessary configuration the properties bar would be editable if not it is what it is now, read only.
At the end a consistent user experience, less work for the node authors and more editor capabilities (edit multiple nodes in one go) could be achieved.
Is that Idea any good?
2 Likes
Hi @Christian-Me,
I had a similar thing in my head for similar reasons. Had found some third-party libraries, but then Nick suggested (in that same discussion) that this kind of stuff would have to be part of the Node-RED json editor. I.e. simply pass a json schema to that editor, and one second later you have a nice UI.
Since he was absolutely right I immediately started coding. After a few weeks I had already quite a major part of the specification implemented, but it became quite difficult at the last bits. Due to lack of free time I had to quit at the end. This project was just to big to accomplish in little time...
Bart
1 Like
Yes I remember that post and It addressed my love hate relationship with the JSON editor in general (working on big ui-table definition making the json unusable just because I missed a comma somewhere - hope this is solved with the monaco editor) I ended up using vscode for editing my JSONs. But this is another story.
I just looked into the visual editor again and had not a positive experience - sorry to hurt someone’s feelings.
Because I have a defined scheme in mind I would focus on the existing property bar and add what is already there in conjunction with the existing editor widgets. Certainly in the end a unlimited visual JSON editor will be the result if you leave away all restrictions of the scheme.
I’m at this point not qualified (and limited by the time available to spend) to start such a project but would be more than happy to contribute in such an effort (even if I personally have most of my config UI issues solved for now). An editor to build an editor could be a nice icing on the cake 
but a simple object should do it - or the editor could be used as an editor for itself in the end 
I definitely NOT jump at my keyboard right now. More interested in thoughts around this and if there is a need for it at all or if it is just another stupid idea of mine nobody needs
Putting aside the built-in visual JSON editor (although, please remember, it will never improve if no-one feeds back suggestions on how it could be better).
The problem with this is we end up with two different ways of editing nodes. And that inconsistency will make for a worse user experience.
There are many nodes where there is logic built into the edit dialog for how the properties relate to each other and what validation is needed. There are often nodes with legacy properties that need to be handled, and other logic that goes far beyond what a JSON schema might encompass.
Allowing a user to bypass the oneditprepare/oneditsave functions a node has would likely break some nodes and allow for invalid and improper configurations to be applied.
That's not to say we couldn't provide a better way to generate a node's edit dialog from a schema of some sort. That would be useful - and we already have the groundwork for that with the subflow property UI work.
So yes, there is something to look at, but I don't think making the info table editable is appropriate.
One of the things I liked about the json schema, was that you can have an infine depth of nesting levels, and arrays of objects.
Yes, monaco will format bad json...
2 Likes
Making the Format JSON button more forgiving is on my to-do list... Unless anyone else wants to look at it. Relying on a hidden feature of Monaco isn't ideal.
1 Like
I love recursion! Until you run out of horizontal space to display your family tree.
@knolleary you are right the the user experience is a main objective here. And yes the node has to be able to keep in control of the data to avoid anything injected from the side the node has to deal with
Working with many huge CAD systems showed me that more and more go away from popup dialogs to unified property bars. They can’t solve everything but can do the basic things. In many cases the property bar sit aside the classic dialog popup in perfect harmony.
Most important is a JSON validation before closing the editor to warn users that they have a malformed JSON. That is the trap I went into more than once (making a lot of modifications and the last one doomed my JSON - not feasible to refresh the browser and forget about everything because of all the other changes before)
When I was integrating the json schema into the Node-RED json "Visual editor", it didn't allow room for incorrect user input anymore. Some examples:
- Required object properties were automatically to the editor, and the 'remove' menu was disabled/hidden for these properties.
- The number of items in an array were limited between the specified minimum and maximum.
- Based on the property type (number, string, ...), I showed the corresponding TypedInput widget. For example a "num" widget for a numeric property.
- For the build-in formats I applied regular expressions to limit the user input.
- The options in the menu were automatically limited based on which object or property was selected.
- And so on ...
I found somewhere an old animation of how such an email address validation looked like in my setup:
Note that the other object properties (productId, productName, ...) are 'required' so they had been added automatically without user intervention.
A json will always be rather technical, but imho I think this would have been user-friendly-enough for the config screen for some of my nodes. Even more if the "Edit json" tabsheet would be hidden ...
Now I will shut up about json schema's 
For what I think the properties bar should look and feel is following the same scheme most config dialog already look like
- two column layout: property and value
- objects will group values with a (collapsible) header
- arrays will have a header with an add and remove button to add a value (GOTO 1) or object (GOTO 2)
- custom elements were the node can add what ever is necessary
Perhaps this screenshot makes the similarities clear
Left ... an organized mess, right organized but unfiltered with a lot of background noise
The schema could contain (things that pop into my head now ...)
- property
- human readable label
- value type(s) (see typedInput) with limits and other definitions according to the type
- all types possible by typed input
- color
- size (width) or height / width (as dashboard widgets)
- ....
- user defined widgets
- validation callback per value (to give a kinds of freedom)
- validation per node (as soon as the node loses focus)
- callback as soon as the node gets focus and the properties bar is or will be displayed
- callbacks for all kinds of events (onClick, onChange ...)
- callbacks for add and remove elements in an array
- placeholders
- tooltips / context sensitive help
- styles like visible / disabled or other css stuff
- allow or prohibit edit together with other nodes
should be controllable in a cascading style (inherit from parent if not defined)
If more than one node of the same type is selected then properties can be edited together. If they have different values it is indicated but can be still edited (if allowed by the schema). If different types are selected the user can filter them by type or only common properties like enable or dashboard groups.
To avoid a inconsistent user experience the config dialog can contain the same "widget" but with a more flexible style (no table, more or exactly the Node-RED standard styling). Objects can go into tabs, arrays into editable list ...). Or still use an individual UI.
Here are some examples of my day to day work: (Autocad, changes are done "live")
or (Revit, wirh an "Apply" button and many popup dialogs "Edit ..." )
Blender / Freecad (similar) both with a tree view like Node-RED (which I would use more if it expands to the selected node by itself)
Here a little bit in action: Nothing selected, one line, two lines / changing the color together)
Or web based:
Not from my daily experience: And last and least VisualBasic 
(But with a help window- Really useful)
OK perhaps a stupid idea.
I do agree having a quick way to edit a nodes properties would be great. But we cannot just forget about the way it works today. The oneditprepare/oneditsave functions play a vital role for many nodes that is closely coupled to how they update their properties.
Posting screenshots of other apps doesn't help address that fundamental problem.
It's about having two ways of editing nodes providing an inconsistent user experience.
It's about having 3500+ nodes in the library and needing to consider what the user experience is when some support being edited in the sidebar and most don't.
Don't get me wrong and I get your point and respect your concerns.
My examples should not convince anybody that this is necessary at all. I gave them to show the common mechanics behind many properties bar - open source and commercial products.
All these examples have an evolution behind them too ... Certainly +3500 nodes and an established API / logic ... is a big tanker and not easy to turn and a great responsibility to avoid potential hazards.
I don't see an automatic transversal from the current way to an editable toolbar too. The author will have to at least define the schema for his config otherwise it will stay as it is "read only" or any attempt to do so will open the config drawer.
If a transformation period leaving some nodes as "classic" nodes (to find a nice name) is not desirable or unacceptable that's understood.
1 Like
I think I have misunderstood something about the impact on existing nodes. I thought that this would be a ProprtyGrid widget, similar to e.e. an EditableList widget. And that node developers can use it if the want?
Certainly it is intended to be optional but as @knolleary correctly mentioned as soon as it manifests outside the node itself inside the property panel it could disrupt the user experience. As some nodes will support the editable property bar and some not.
The oneditprepare / save mechanism will prevent a editable property bar with a flip of a switch. So the node Autors will have to implement it activity.
A valid concern.
Currently available solutions may look somehow limited but there is also good side. It forcee developer to do same as simple thing. So the configuration will not be a scientific route but familiar route. Yes it can be obstacle if the amount of properties goes to heaven but that is also a good limitation. Having found Node RED yesrerday the confusing configuration page does not help any way. Balancing out whati is possible and what is meaningful is the key thing to catch out.
Personally I would hate a bunch of editable properties. Just dumped as a list of properties without any context and not well named. Maybe great for geeks under the covers but no thank you. The original idea of the config panel was to make properties more “conversational” so they led the user through what needed to be set etc. ok so that has somewhat fallen by the wayside as some nodes have got more complex -but I don’t think just exposing them all as an editable block would be a step forwards.
1 Like
I would have to agree here and agree with Bart. I don't think that putting a generic editor into the sidebar would be a good idea.
However, having just spent a LOT of time trying to wrangle uibuilder into having a better editor experience, I can say that you do seem to need a bit more boilerplate for a node's edit panel that is ideal.
Some additions to the existing widgets would probably go a long way. Also, having some additional events in the editor would also help. For example, being able to tell if a property has changed from its last deployed setting would be extremely helpful. We also have property validation functions but they are triggered differently to when the UI itself is changed which is confusing. We also can't tell in a node's edit code when the node is initially displayed vs when you open the panel. The validation functions are triggered multiple times without any way of telling at which stage things are at.
Personally, I would like to see a much simplified method for creating the edit panel without needing so much HMTL boilerplate and mixed jQuery JavaScript. That would be a great benefit. It also could be offered as an alternative to the html method rather than a replacement - so being backwards compatible. It would also result in the same HTML UI, just specified as configuration rather than code.
@TotallyInformation Indeed - as I said earlier in this thread:
It would likely have to be a 3.0 type feature - as any node that made use of it would not work at all in previous versions.
As for your other suggestions, if you have any more concrete suggestions to make, then please do so.
You mention this as an example event... when would this event be triggered? We already have the nodes:changed event that is emitted whenever a node is edited (such as when the edit dialog is closed) - do you mean it would be helpful if that event included more details of what has changed?
That is true - the one function does do double duty. So are you saying you'd prefer a separate function for when the node is being edited versus when it has been imported?
Do you mean in the oneditprepare function? No-one has asked to be able to do so, and I can't say I've ever come across a scenario where this is needed. If you have a specific use case where this would be useful that would help understand the requirement more.
you can have an infine depth of nesting levels, and arrays of objects.
Which is exactly why it's a REALLY BAD idea from a user experience point of view
