Pop quiz! Test your understanding of channels!

[kegghead]

NI has hammered home the idea of data flow along wires since the beginning. I think to be consistent the connection between channel nodes should never be called wires. There is no flow. They're channels, not wires.

Make the grahpical presentation of channels different than wires, keep terminology consistent, and you just may have a chance of not utterly confusing people.

I think you're on to something with the green background thing:

To me it's clear something different is happening here because the channel itself changes when we change scope. I think this is a fantastic idea and shouldn't be just for debugging. That said the difference needs to be more obvious. The channel needs to look different when it's running through any scope other than that which contains an end point node. Change to a dashed or greyed version or something?

Conceptually the idea here the behavior of the graphic denotes a channel rather than a wire. Wires are static, with the exception of dynamic dispatch propagation on a class wire, a wire doesn't change in apperance.

I don't think you can pin down a graphic alone that is obviously a channel. Thickness is arbitrary owing to arrays, color and patterns are arbitraty thanks to classes. The only thing I can think of that will allow you to show "this is different" is the behavior of the graphic as it reacts to the code. This behavior is different than the dynamic dispatch wire behavior and may be made unique to channels.

I realize the image above isn't ideal. What happens when a channel is passing through some VI with no end points? Then we're back to the original problem of having only the single graphic, with nothing to show it's different than a wire. I don't have an answer to this.

[AristosQueue (NI)]

Here's an image to contemplate:

[sth]

I like the transparency, but not much lighter than 40% or it starts to fade into the bckground.  I like the removal of the tunnel indicators since there isn't really any interaction at that tunnel boundary and having a marker there seems to imply that the boundary is a special point.

The bezier curves help distinguish it as a "different' kind of data flow, but they also make it look like an aftermarket ECO to correct design errors.  Not really what you want to communicate. 🙂

[Thoric]

Nice. The Channels layer is unrelated to the normal block diagram layer, and can bend and reform as required to join nodes. Manipulating subVI and function positions doesn't worry the Channels wires, they can adapt with ease as you've sketched.
I'd still like a way to switch their visibility eaily. At a single keypress preferably. Perhaps between 100% and 20% if not entirely invisible?

[Mads]

2D/3D/4D - it still makes a mess. The point is that people are used to think of such connections as invisible; they might as well occur in hyperspace. - Things originate from somewhere, and then pop up at known receiver points.

Wires are almost instantaneous in conveying all information about the link when isolated to a block diagram, but as soon as the link crosses multiple barriers, and there is no execution control linked to that path - wires become difficult to track and comprehend. The more intuitive solution then is to utlize people's relation to real-world wireless connections. People have a natural inner picturefor such that is much better than a 2D/3D picture can convey.

Finding a good way to 1. establish the mental image of such a link, and 2. provide enough details to enrichen that mental image should be the next question...In the crude example above the wireless symbol is supplemented with info on which end-points there are, whether they are actively listening or just have the link set up on their block diagram... etc. - and provide jump-capability to those...)..

[tst]

How about these visuals:

Pretend that the reentrat VI has some mechanism inside to prevent deadlocks.

[sth]

I like the visual part of the wire or link.  Since these are channels not a radio broadcast into the ether they have specific endpoints.  Know the links between endpoints and the channel is essential.  Having multiple channels then gets very confusing and knowing which endpoint is associated with which channel is essential.

I like the green coloring option for the buffered location of data that is accssed by the various channels.

[AristosQueue (NI)]

Mads wrote:

The more intuitive solution then is to utlize people's relation to real-world wireless connections.

Our observation is that a sufficiently large number of our users have no such intuitive sense such that we believe a wired depiction is desirable. That's what's driving this feature. As I said previously -- discussions about a wireless solution, while interesting and possibly relevant to some future feature, are not relevant to the design of the wired feature we are working on.

[Amiri]

AristosQueue wrote:

a) How do you feel about Feedback nodes?

b) Is there anything visually that we can do to draw the connection such that it shows a connection without implying "wire"? The current draw style came about after multiple people said, "you know, that channel doesn't really look like a regular wire; I think I could learn to 'see' it differently." But we may need to go further.

                   

a) I like Feedback nodes

b) How about a floating (3D) dotted/dashed line?  When you see a dotted line in, let's say, an org chart, you know that there is a special type of "connection."  Similar to what @tst drew up, but floating above everything.

Even as is, I think the Channel wire looks pretty good, other than it looks like a queue wire.  And the subtle look of how the wire looks across a loop boundary is enough to tell me something is different here.

I like the discussion here by Thoric about having this communication channel as a layer that you can select and toggle to adjust the transparaency so that you can "see" it.  That coupled with Mads idea of having some sort of connection manager that can quickly be pulled up would be amazing.