This has been evaluated and rejected a few times by R&D, though I don't think it has ever come up on the Idea Exchange before. The problem is that there are a finite number of patterns that we can switch to. In order for this idea to have any traction, it needs to be more than "please make them different". It needs to be accompanied by specific wire designs that you would like to see for each of the types.
I am not going to ask to have this idea closed at this time. I am going to lay out in the next couple paragraphs why R&D rejected any differentiation. This is not the same as saying we are closed to the idea. You may have a design idea we haven't thought of. If so, please post it so other users can evaluate it. If, however, we go several weeks and no one has a design, I'll probably ask that it be closed as noise and if anyone comes up with a specific idea later, they can post it as a new idea.
The first problem is simply that we do not want to make massively different appearances for wires needlessly. How often do any pair of these occur on the same block diagram such that cross wiring them is an issue? It's surprisingly uncommon. I'm not saying it does not happen, but it is less common than a lot of other types that we do not differentiate. When we observe customers (and we saw this a lot when we first introduced LV classes), a proliferation of unique wires (color or pattern) creates as much strain on readability as it solves. Things that look alike tend to behave alike. So we want to only introduce differentiation when needed.
We need these to look like references. That concern trumps all other concerns. In a massively parallel environment, a reference wire needs to be clearly obvious and totally recognizable in any context. Any redesign needs to maintain that clear declaration that "this is not a value type and has significant ramifications if branched or stored". That is going to limit design brainstorm space in terms of border color and border style.
Borders themselves are a problem. Color bleed is a major issue. Although we have picked refnum cyan as the border of these wires, if you use your favorite drawing program to change that outside border around many of the common wire types, you'll discover that the outer border looks the same to most users for a pretty wide range of colors, and for those who have any amount of color impairment, that border really blends.
Adding more width is almost a non-starter. The wire is already as large as the terminals on the commonly-used 5x3x3x5 conpane. Any wider on the standard data types and it becomes a wiring hazard.
That pretty much leaves you with getting rid of the core. And seeing the core data type for all of these is pretty important.
So that's why they all look the same. If you have design proposals that you think are viable, post them here and let's see what other users have to say.
The blue outside is refnum cyan. All refnums carry that cyan. That's part of the visual cue that this is a reference and is something we generally feel would be very bad to mess with.
As for the white dashes in the middle, that's the cluster wire. That's not up for change unless you're saying you want to remove the core data type. Remember -- the core of these wires can be ANY LabVIEW data type.
Oh yes- point taken RE core data type. So if the cyan can't change and the wire can't get any thicker (agree it's thick enough already) there's no possible room for manoeuvre and the idea may aswell be rejected.
You've reversed my opinion on this one, Aristos. Don't think it's possible to rescind a Kudos... 🙂
@ToeCutter: Darn. I was hoping you were going to suggest a new idea. I'd kind of like to have more differentiation here. I would like to differentiate visually the DVR from all the communication refnums so that those that are consistent with asynchronous dataflow (notifier, event, queue[in most use cases]) are distinct from those that are completely breaking dataflow (DVR). But I haven't seen a way to do it.
@Aristos- The only other possible option is some sort of stipple in the cyan sheath, but I suspect that would make the whole thing look too messy. TBH, I've never actually had the problem of confusing these items, so not a big problem as it stands.
