Feature Request: Publish as List/Value
Frederick,
Here is a VERY simple feature request that could make NodeBox a lot easier for both experts and newbies. Instead of providing a single Publish option when creating subnetwork ports, offer two options: "Publish as value port" and "Publish as list port".
JUSTIFICATION
In order to publish nodes in a subnetwork you currently control click a port on a node inside the subnetwork and choose the only option: Publish. Sometime later you have to select the subnetwork node, open the Metadata dialog, select each port, and verify or change the range setting to either value or list.
This extra step is a pain for experts and major source of confusion for newbies. Because it is undocumented, newbies are not even aware this option exists; in fact many aren't even aware of the Metadata dialog. Even if they find Metadata, the Range option is inconspicuous and deeply hidden. NodeBox tries to guess the range, usually defaulting to value, but it often gets at least one port wrong with disastrous results. The worst part is that when this happens there is no obvious reason WHY.
The distinction between list and value should not be hidden from newbies. Just the reverse: they have no hope of using subnetworks without understanding this distinction. Over the years I've come to understand that the whole point of subnetworks is to coordinate input streams using value vs. list. The UI should put this distinction front and center.
Fortunately there is a VERY simple solution. Instead of providing a single Publish option, offer two options: "Publish as value port" and "Publish as list port".
For experts this would be a huge time saver - they would almost never have to wrestle with the Metadata dialog ever again.
For newbies the benefits would be profound. By forcing this choice at the outset, at the moment the user is thinking about each input, newbies will immediately grasp that there are two different ways of feeding data into a subnetwork. If they don't understand the difference they can just pick one at random (which is essentially what is happening now anyway). But even then they will at least *know* that there is something they don't understand. If they want to seek help it gives them something specific to search for. If they just want to learn by trial and error it gives them an obvious thing to try.
Replacing the rather vague "Publish" with the more specific "Publish as value port" or "Publish as list port" will also help newbies grasp the concept more quickly and remind them to think about it each time they add a port. Even experts would benefit from this reminder.
I can still remember how painful and confusing subnetworks were for me at first. I've spent several years now seeing how hard this feature is to understand for most new users and thinking about how to make it clearer. As an interaction designer I have a number of other ideas that would take more work. But this one change would be easy to make and, I think, would be a huge step forward.
John
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Frederik De Ble... on 20 May, 2018 01:41 PM
This is a great idea! You're right, understanding this concept is key to working with subnetworks / functions.
Support Staff 2 Posted by john on 20 May, 2018 09:12 PM
Frederick,
Just for the record, a related idea is to also make the distinction between value and list more visible in the network pane.
Draw list lines slightly thicker than value lines (and make list port nubs slightly wider). Or draw solid lines for list connections, dotted lines for value connections (to convey that lists come all at once while values come one at a time).
This would make debugging easier - you would no longer have to open Metadata to check the range of each port. More importantly, it would make the value/list distinction even more prominent, helping users to understand its importance and more accurately visualizing the true nature of the network.
One of the things I love about NodeBox is the way it lets you see your code. This idea would let me see even more.
Just a thought. But don't let it delay the implementation of the first idea.
John