As I get further along in my first real contrib-node project that isn't just for my personal learning or a proof-of-concept. I'm now faced with the question, "How do I keep my node from becoming overly complex for some users, particularly beginners using a low code platform, while still providing powerful features to experienced developers"?
I've been receiving some solid feedback on feature requests for the first time, but I'm a little uncertain on how I would like to proceed. What strategies do the rest of you employ? Would it be better to try to split it into multiple nodes with limited features each, or maintain it as a single node? What other options might I have that I am unaware of?
Sorry if these are not very good questions, I'm entirely self taught so sometimes I struggle in unfamiliar territory.
Nothing wrong with the question at all, its the answers that might not be right.
My answers may differ from others - but that's almost the point I will make, it's really down to the goals of your project.
Is it for those who can understand complex environments
Is it for those that need big colourful buttons
Best of both worlds
Don't be afraid to withhold feature requests, if it's not inline with the goals of your project. I have declined many feature requests that don't suite or will taint the goals of my projects.
If feature requests that you would like to implement, may be to difficult to understand by most end users, then maybe add Nodes for advanced users - or build your nodes in a way, that allows users to easily switch to 'god mode' if they so wish.
And most importantly, sound documentation/examples of features are a must! - I use GitHub Wiki for that.
I don't believe there is a single right answer to that. Personally, I prefer to minimise the number of nodes - but only so far. If a set of features stands separate from the main node, then it gets a new node.
The age-old question! In my view, the trick is to think like your users. Perhaps you can identify a couple of user-persona's - a beginner and an advanced user maybe, or something more focused on what the node does. What are the typical things they will want to achieve using your node(s)? It doesn't hurt to write these down to give yourself something to work with.
Then you need to start organising any settings from the most common through to the least. And possibly the easiest to the most complex.
The most common settings will be up front and easy to access, easy to use. Less common/more complex settings might need to go on a separate tab.
If a task is really complex to configure - then maybe that is a good candidate for a separate node.
The common rule is that the node should do "one thing". It is not always easy to determine boundaries but in case of dilemma try to keep safely on "not" side.
I think the problem may lie in the scope of the nodes abilities. The use-cases of large language models seems to be so broad that I'm not really sure what the majority of users will be using it for. And my goal is to make the node as non-restrictive in it's use, and to be as user friendly to beginners as possible. I like the idea of helping new developers easily access the power of modern AI models in a platform like Node-RED.
Also thank you for providing an example. Quality examples are the number one resource I have found to be useful in my learning.
Yes - it's all a balance. As mentioned ideally it should be "obvious" what is a node is for and it should try to do that thing well. (That thing may be simple or may be very complex). But yes - forcing users to take loads of extra nodes into their palette that they may never need is also not good. It sort of depends how well the variations you are talking about fit under the same heading so to speak.
Don't be afraid NOT to add features to start with... start simple and evolve only when really needed - don't just add features because you think someone may want them.. as users may well never actually need them. And once added you can't easily remove if you suddenly find a better way to do something.
Great question, but it strikes me as having two parts: how to deal with feature requests and how (whether) to implement them. On the first, I have an informal system that rates requests on a rough scale. On the bottom is: "it would be nice if..." If the change is basically cosmetic, appeals to my "aesthetic" sense, and is easy to implement, it can go directly to the queue for the next (bug-fix) update. If it fails that test, I try to engage the requester for input that would move it up the scale. At the top are very specific requests like "I would use your node for x, if only it had y." That makes it possible to balance the cost of implementation against the benefit of increased capability. Obviously, there are intermediate cases, and discussions can end with the requester going away or making changes in his/her own copy or fork of the node.
One approach I've liked is to create multiple modes in a single node that can be selected, but that hide as much of the complexity as possible. A very simple example is node-red-contrib-random-event-generator, where the parameters needed for each mode are visible only when that mode is selected and parameters for the other modes are hidden. This has to be explained in the documentation, but it's fairly obvious.
Several things can happen here. My less-than-expert advice is:
If a new feature adds significantly to the basic function of the node or makes it much more widely useful, add it. Try to manage any increase in complexity for the user.
If it adds capability that is only marginally related to the basic function but would benefit an "advanced" user, consider writing another (possibly modified or derivative) node. Assume the user is willing to deal with more complex function or interface.
If the logic of the change is incompatible with the existing node or the implementation is very difficult, start over, if motivated.
This seems similar to my current approach of using msg.topic to determine the node's behavior mode. Although I like this method I worry that it may still grow too complex as the project develops.
I think maybe I am being a little to eager to please (mostly because I want some successful projects under my belt), perhaps I'll be slightly more reserved about completing all feature requests right away going forward. I may need to develop a system like you've described instead.
Good point. I was looking at the complexity of the ui in the node edit dialog. Constructing input messages or parsing outputs is another area where things can get out of hand.
Also, I just want to say thank you all for the feedback. This forum is an invaluable resource to me. I have never before seen such a informed and helpful community online.
I do strongly recommend creating a roadmap document. I've done this from early on with uibuilder as it was quickly obvious that there were a never-ending set of things that could be extended and improved.
You have to prioritise and you certainly can't afford to let the node become a burden if you are in it for the long haul.
The roadmap also helps you outline and keep the shape of what you are trying to achieve so that when requests come in that don't quite fit, you can park them somewhere and mull them over or you can politely decline them because they don't fit your overall goals.
Personally, I love other people's input, no matter how wild or whacky, but I've some principles that my nodes will need to stick to and that is summarised in the roadmap along with all of my own and other peoples whacky ideas. This also recognises that not everything can be done at once - nor should it be. Somethings take time to gestate. Better to take six months and create something that becomes a foundation for further development than rush in and end up blocking other, more important later changes.
So don't lose the eagerness and fun. But do weave it into a coherent long-term story.
it is a mess derived from the madness inside my noggin! And is an ongoing (never ending) effort - if you get sucked in, don't blame me, I warned you! 
