Labels for Outputs

[Humancell]

It would be nice if there was a way to label the outputs, so that when I'm connecting nodes I could mouse over the output and see a tooltip pop-up that tells me what the label is.

[timonsku]

+1 that would be incredibly helpful

[vincentjames501]

👍 This would be awesome!

[timonsku]

Are there any plans to ever imeplement this?

[knolleary]

We don't have any current plans for this.

[timonsku]

Thanks for the heads up

[vincentjames501]

@knolleary , is this something you would consider a pull request for or are there hesitations about adding this?

[knolleary]

@vincentjames501 it isn't about priority/bandwidth to implement. It is a question over whether the utility of the feature is worth the code overhead, the changes to node structure and the UI changes to support editing etc on a per node basis.

[timonsku]

Atleast for me and the company I work for its a huge dealbreaker to use node-red. Take for example nodes that you wrote in JS adhoc, in order for someone else to know what it spits out at what output, you will always have to read the description (if there is any) or read the code.

Which really prohibits fast intuitive programming imho, just taking a peak at the output name would give you a big clue about what the output is acutally doing (or simply reminds you in case you forgot). RIght now you can have many indistinguishable circles presented to you without really knowing what is going on with them.
Take VVVV for example, they do this quite nicely.

[knolleary]

@PTS93: thanks for the feedback - that is useful. We have to prioritise what we work on and have to do that based on demand and perceived value. To date, as you can see from the comments, this had received only passing interest.

[timonsku]

I figured, glad to give feedback. I hope this maybe starts a bit of a discussion about the feature if other people actually have interest in it. Though I do think that there is quite some interest there, even though there aren't many comments here, there definitely are a few duplicate issues talking about a similar feature.

[vincentjames501]

I agree with @PTS93 that this feature would be extremely useful and would help one more easily visualize the flow of data. I was tinkering around and one option that would be easy to implement is just tooltips when hovering over the ports.

When registering your node, we could supply a portlabel(portIndex) function to get the text of the tooltip (similar to the label function):

portlabel: function (portIndex) {
  switch (portIndex) {
    case 0:
      return 'First Tooltip';
    case 1:
      return 'Second Tooltip';
    default:
      return 'Other Tooltip';
  }
}

In RED.view append the tooltip:

var $tooltip = d3.select("#chart").append("div")
        .attr("class", "pipe-tooltip")
        .style("opacity", 0);

Override the current mouseover and mouseout events for the pipes:

.on("mouseover",function(_,i) {
    var port = d3.select(this);
    port.classed("port_hovered",(mouse_mode!=RED.state.JOINING || (drag_lines.length > 0 && drag_lines[0].portType !== 0) ));

    var coordinates = d3.transform(d3.select(this.parentNode).attr('transform')).translate;

    var portLabel = d._def.portlabel && d._def.portlabel.call(d, i);

    if (portLabel) {
        $tooltip.transition()
            .duration(200)
            .style('opacity', .9);

        $tooltip.html(portLabel)
            .style('left', coordinates[0] + d.x - 100 + 'px')
            .style('top', coordinates[1] + d.y - 30 + 'px');
    }
})
.on("mouseout",function(d,i) {
    var port = d3.select(this);
    port.classed("port_hovered",false);
    $tooltip.transition()
        .duration(500)
        .style('opacity', 0);
});

Some css:

div.pipe-tooltip {
    position: absolute;
    text-align: center;
    width: 60px;
    padding: 2px;
    font: 12px sans-serif;
    background: #ffffff;
    border: 1px solid black;
    border-radius: 8px;
    pointer-events: none;
}

[hardillb]

The biggest problem is not how to display the info, it's more how to gather output names. It would need changes to all (well any that have more than 1 output) the existing nodes and a sensible strategy to add it to the config dialogues so as not to clutter them for the ones with dynamic numbers of outputs.

[vincentjames501]

@hardillb I would simply make it an opt-in process. If you would like tooltips on your input pipes you must implement something like inputportlabel(portIndex) and if you would like tooltips on your output pipes implement something like outputportlabel(portIndex). If they don't implement them, then no tooltip is displayed. My code snippet above handles this gracefully (though the code is more for discussion purposes than anything else).

[gabejohnson]

I think @vincentjames501's approach makes sense for newly authored nodes and should be backward-compatible. As for updating existing nodes to allow users to add labels, that seems like something one would tackle on a node-by-node basis (if at all).

[dceejay]

but isn't the main place for this on nodes that don't have any info documentation - like functions, change nodes and switch nodes ? If so how would the end user add them ? (without really messing up the edit dialogues for an option many may not use)

[gabejohnson]

@dceejay I would argue that switch nodes would easily accommodate custom labels with a checkbox to make them optional. When adding a new case replace the enumeration with a text input. However, I'm not advocating that change. As for the change node, it doesn't allow multiple outputs.

I think custom output labels would be a nice optional feature for authors of new nodes that can have multiple outputs.

[timonsku]

Labels definitely need to be changeable by the end user, in cases just like dceejay mentioned.
Maybe have default names which are chosen by the author of the node but if you want to rename them, you could do this by ticking a checkbox in the edit menu and getting a new tab with all the labels listed (make it a scrollable list if there are more than x outputs).

If a node has no default names assigned they would just be named after their index by default (out0, out1 out2 etc.)

[dceejay]

I would argue that adding labels like out0 out1 do nothing to help the user. The label would have to describe something unique about that pin - which only (to me at least) applies to nodes with multiple outputs. And adding a tickbox... would itself need a label so you know what it does... again taking up real estate.
There have also been competing thoughts as to use of mouseover on pins... like a dynamic debug probe for example, so we don't want to fix this just yet.

[timonsku]

I wouldn't literally label them out0 and out1, I just think a programmatic default would be better than that nothing happens on a mouse over for certain nodes. If there is always more/better information about an output available than its index than that should be used.

[shrickus]

I have to agree with @PTS93 on this one -- without this feature, I spend lots of time opening editors and reading code, just to get info that I need to connect a wire...

Prior to finding this thread, I actually prototyped this to work on my switch nodes. This way, I can see what rule is active for each output port without opening the editor. At runtime it looks like this:

@vincentjames501, I do like the idea of registering an optional portLabel: function (portIndex) in each node.html template file. However, instead of using mouseover events, I chose to implement the title popup as a child SVG title element inside the rect used to draw each port:

<g class="port_output" transform="translate(115,8.5)">
    <rect class="port" rx="3" ry="3" width="10" height="10">
        <title>payload.tagname is null</title>
    </rect>
</g>
<g class="port_output" transform="translate(115,21.5)">
    <rect class="port" rx="3" ry="3" width="10" height="10">
        <title>payload.tagname == 'EL.Site.Purchased.kWh'</title>
    </rect>
</g>

Of course, the name mapping for switch nodes is straight-forward, but functions and other dynamic nodes (or subflows) would need the designer to give them a human-readable title.

[sandro-k]

Nice to see some interest in this feature. My colleges and me taked about implementing this too.

[PerMalmberg]

+1 for this feature.

[Banbury]

I consider the lack of clearly labeled input and output nodes the biggest flaw of node-red. A flow should be readable without constant reference to the documentation of each node.
Add to that, that every node uses the msg object differently. Which forces me to insert function nodes, that rewrite the message. And these are then unlabeled, too, and have no way to be documented.

[knolleary]

Allow nodes to specify labels for their ports

[troywweber7]

the documentation makes it seem like this already exists: http://nodered.org/docs/creating-nodes/appearance

but apparently it doesn't...

[knolleary]

@troywweber7 hmmmm yes, that shouldn't be live yet (or should make it clear its an upcoming feature that nodes can add support for in anticipation of the 0.17 release)

[dceejay]

added a note to the docs to clarify

[virtimus]

I think this issue can be closed - on 0.19 working fine - One can add labels (using node settings) on subflow template and also on subflow instance level - great :)

[knolleary]

Closing as ports can now have labels. Missed the 5 year anniversary of its opening by one day.