Feelings on Icons for Terminals?

[GregSands]

Emphasizing the inputs and outputs distracts me from what I'm really interested in, which is what the code is doing. Terminal icons are too similar in shape and size to sub vi icons, and to a lesser extent class constants.

You beat me to the comment -- this was exactly my first thought on seeing this image. I also always use terminals - I cannot think of a time I willingly used icons - perhaps only when coding on someone else's machine.

[Tim_S]

I pretty well despise icons as they don't show me more information and take up more space. I wasn't aware that they show more information with objects, etc., yet I don't see that as enough for me to turn them on. I find Daklu's visual identification argument quite convincing as I have quite a few VIs that I routinely go into with dense block diagrams; quick identification is very important to me with these as I regularly are on the phone with someone trying to resolve a problem.

Tim

[hooovahh]

Pretty sure you could have abbreviated that and it still would have been funny.

[asbo]

Pretty sure you could have abbreviated that and it still would have been funny.

I found it more amusing to preserve it verbatim.

[drjdpowell]

Yup. But my style is to have control labels to the left, indicators to the right and for them to be stacked closely to lessen wire bends.Of course. I don't suffer as much from the "obj" problem

Well, I certainly can't pretend that isn't a very clear diagram. But that "refnum", that's actually a cluster, is really making my OCOOD act up! It's an Object! It's an Object! Quick, quick, open an icon editor! Aaarrrggghhhhhhhh...

[ShaunR]

Well, I certainly can't pretend that isn't a very clear diagram. But that "refnum", that's actually a cluster, is really making my OCOOD act up! It's an Object! It's an Object! Quick, quick, open an icon editor! Aaarrrggghhhhhhhh...

No its not (an object). It's just a container like a string, int etc that contains raw refnum data. Why complicate it by adding 15 new vis just to read/write to it.

[drjdpowell]

I greatly prefer the icons (as James knows) because:

Oh, are you "paul.dct" on NI.com?

See everyone, another unicorn.

Terminal icons are too similar in shape and size to sub vi icons, and to a lesser extent class constants.

I must admit, I wouldn't mind the visual distinction of a control from a VI (the border around the icon, little arrow, etc.) being a little more obvious.

-- James

[drjdpowell]

No its not (an object). It's just a container like a string, int etc that contains raw refnum data. Why complicate it by adding 15 new vis just to read/write to it.

Raw refnum data? Does the cluster also have an enum or some such that identifies what the refnum specifically is? That you use to decide internally what bit of code to execute? Your right, that's nothing like an object; it certainly doesn't need an identifying icon. I'm feeling calmer already!

-- James

PS> I just noticed the 3D raised effect in your subVI icons; nice!

Edited October 26, 2011 by drjdpowell

[PaulL]

Oh, are you "paul.dct" on NI.com?

Yes.

[mje]

My dislike of the icons I think mostly stems from that they never existed for the longest time, so their size is just so off-putting.

In theory I think icons are good for object heavy code, as I hate having several different "OBJ" terminals which I can only distinguish by color/wire ("Was the "Foo" widget brown with hashed wires or blue with dotted wires?"). In practice I still can't bring myself to use icons though, they just feel so...wrong.

[Aristos Queue]

My comments on this topic are here:

http://forums.ni.com...c-p/927234#M577

After you disagree with me, you can add your kudos to the idea exchange entry. :-)

Proud to be a unicorn!

[mike5]

Small terminals!!!

And while we're on the subject, can you maybe change the LV behavior to automagically convert the terminals to the user-preferred type. BecauseI really don't like it when I open a VI on a project someone else created and see the icons instead of small terminals. Not to mention block diagrams that have both mixed

But I actually do like icons in one case: cluster constants

Mike

[ShaunR]

Raw refnum data? Does the cluster also have an enum or some such that identifies what the refnum specifically is? That you use to decide internally what bit of code to execute? Your right, that's nothing like an object; it certainly doesn't need an identifying icon. I'm feeling calmer already!

-- James

PS> I just noticed the 3D raised effect in your subVI icons; nice!

No enum. The refnum is converted using the "Variant To Flattened String" to give a string and and array (which is clustered together). The type of refnum is encoded in the array as a type descriptor. The descriptor then decides which piece of code to execute and the flattened data is reconstituted for the particular primitive (TCP,UDP etc). It's just a way of removing the type dependency so that the refnum can be passed from one vi to another independent of the interface.

It's all in the Tansport.lib if you want to see how it works.

After you disagree with me, you can add your kudos to the idea exchange entry. :-)

Whats the point. It's has been declined with 322 kudos .

Edited October 27, 2011 by ShaunR

[CharlesB]

This is the kind of code someone using icons ended up with... IUsually when someone uses icons they don't really know LabVIEW

Is that real code??

[Roderic]

Is that real code??

Indeed... I have to debug this application wich is full of locals,globals, and explicit naming VI (like: "dialog18buttons.vi")

[drjdpowell]

An experiment. My previous subVI redone to be more like ShaunR's style:

[Daklu]

...I hate having several different "OBJ" terminals which I can only distinguish by color/wire...

Don't you show terminal labels on your block diagram? I don't think I've ever bothered looking at the text inside the terminal (except for integer types) as the label gives me all the information I need.

An experiment.

Ahhh.... so much better.

[Ryan Podsim]

One of the main reasons I like the terminal style is I can identify a terminal at a glace. Where as with the icon style, I have to think for a second to differentiate between a terminal and a subVI. I suppose, if I use the icon style that would become easier with time.

[drjdpowell]

Ahhh.... so much better.

My experiment illuminated a few things:

1) for small, compact diagrams the smaller terminal size is plenty large enough to be clear, and I can see why they are an advantage to making small compact diagrams.

2) I, personally, find it less tedious to spend time making up lots of icons than carefully aligning and adjusting things into small compact diagrams. I'm perfectly happy with my previous diagram that takes up twice the space and doesn't have the terminals all lined up, yet I'll open the icon editor if I notice a few-pixel inconsistency among related icons. Your OCD may vary.

3) I really don't like the "OBJ" issue. I don't care if I can read the label; although many objects like "Observer Register" will basically never be labeled any different, "Message" objects could easily be labeled "Command", "Response", or "Ack". And the icons sometimes express cross-class relationships, such as the "envelope" icon showing the close connection between Messenger and Message objects, or other relationships among objects, subVIs, clusters, and enums. And hey, LabVIEW's not a text language, don't you know.

-- James

[COsiecki]

Nearly every one of my VIs looks exactly like ShaunR's style. I'm a fan of straight wires and you just can't do that with icons. I actually wish the DVR constant was smaller because its twice the size of an icon. So bulky!

+1 for Terminals

Edited October 27, 2011 by COsiecki

[todd]

Terminals! For the same reasons as above: averse to change; small size; label says it all. If you want to see all the type information in the diagram, how about creating a wire style that has all the type-text from the context help? (Yes, that's sillly.)

[LogMAN]

Indeed... I have to debug this application wich is full of locals,globals, and explicit naming VI (like: "dialog18buttons.vi")

Haha...

I'm so sorry, couldn't hold back.

Getting more serious: I'm sorry for you, not because of icon terminals, but about globals and explicit naming...

An experiment. My previous subVI redone to be more like ShaunR's style:

+1 +1 +1...

I like that

Actually this is also my style. More readable, easier to find terminals, less space, more flexibility.

You should use your own style of programming, but please don't mix everything up, that would make things unreadable.

2) I, personally, find it less tedious to spend time making up lots of icons than carefully aligning and adjusting things into small compact diagrams. I'm perfectly happy with my previous diagram that takes up twice the space and doesn't have the terminals all lined up, yet I'll open the icon editor if I notice a few-pixel inconsistency among related icons. Your OCD may vary.

You know LabVIEW can automatically align your terminals by two clicks?

--> I always spend time to clean up code, since it will come back to me after some time (easier to maintain).

As I started programming in LabVIEW, I liked using icon terminals. At some point they just bother / disturb me and I switched to small terminals. I understand the 'problem' of object or reference types, but I don't understand what you could possibly miss on small terminals for standard types like string. I would say standard types are best to read on small icons. If you don't understand standard type coloring, you should properly change glasses... If you don't remember the type of your object, just switch to FP (icons on FP are much more readable than icon terminals on BD).

Cheers, LogMAN

How comes LavaG post editor does not know words like "LabVIEW" or "LavaG"???

[drjdpowell]

You know LabVIEW can automatically align your terminals by two clicks?

--> I always spend time to clean up code, since it will come back to me after some time (easier to maintain).

Do you mean "select the terminals" and the little pull-down menu of alignment options? Or something better? I did a little CAD work back in the day and I've always found the LabVIEW alignment tools to be slow and clunky. A relatively simple "snap to guidelines" feature (aligning in both dimensions to related objects and also aligning for straight wires) would make it easy to write code clean from the start.

I understand the 'problem' of object or reference types, but I don't understand what you could possibly miss on small terminals for standard types like string. I would say standard types are best to read on small icons. If you don't understand standard type coloring, you should properly change glasses...

I can't say I care that much about the standard types either way. A string is a string. But mixing icons and smaller types means I have to go through the effort of manually changing either the standard or non-standard types. And in larger diagrams, with only a few controls/indicators, I don't see much benefit to the smaller terminals, even for standard types. But I'd be happy to meet people half way if we all want to standardize on small terminals for simple types and icons for objects, type-def clusters and enums, refnums, or anything where the small terminal doesn't convey the full type.

If you don't remember the type of your object, just switch to FP (icons on FP are much more readable than icon terminals on BD).

Flipping back and forth between BD and FP just to figure out what the terminals are? Can't say I like that option for code clarity!

-- James

PS> haven't been keeping up the score; it's a low two digit number to a mere 3.5 unicorns.

Edited October 27, 2011 by drjdpowell

[SteveChandler]

My comments on this topic are here: http://forums.ni.com...c-p/927234#M577 After you disagree with me, you can add your kudos to the idea exchange entry. :-) Proud to be a unicorn!

Can't kudo it because it was declined. I see it was pretty popular there and is also popular here on Lava.

When I started using LabVIEW I used icons. Once I gained a lot of experience I switched to the more popular small terminals. Later still I switched back to icons influenced greatly by your arguments in the link you provided.

There just are not enough controls on any of my diagrams to worry much about the space savings. As for straight wires I just gave up long ago. You can't wire the small terminals to the inputs of a multiply prim without bends for example so it makes no difference in that regard. It is impossible to code in LabVIEW without wire bends so I just quit worrying about it. I do try to limit the number of bends to two at most.

Since it is just not possible to avoid wire bends with or without icons that argument doesn't go very far. The only things I know of that you can wire a vertically compressed stack of small control terminals to without wire bends is another stack of indicators or bundle/unbundle by name. You can't wire them straight to adjacent subVI terminals except in one ironic situation. If you deselect view subVI as icon and drag down the nodes so it looks like a bundle by name or more accurately like an express VI. How many people knew you have the option NOT to view a VI as an icon? Does anyone do that?

As for quickly identifying if it is a control or a VI, well they just look like controls and I can immediately tell by where they are located. You just get used to a particular style after a while I guess and anything else just looks weird and wrong.

There are two situations where I regularly show small terminals. If there is a reason I need to put the terminal in a loop or something or if it is not on the connector pane then I do not show it as an icon. I don't know where I picked that up and just realized that's what I do.

[Jordan Kuehn]

Can't kudo it because it was declined. I see it was pretty popular there and is also popular here on Lava.

When I started using LabVIEW I used icons. Once I gained a lot of experience I switched to the more popular small terminals. Later still I switched back to icons influenced greatly by your arguments in the link you provided.

There just are not enough controls on any of my diagrams to worry much about the space savings. As for straight wires I just gave up long ago. You can't wire the small terminals to the inputs of a multiply prim without bends for example so it makes no difference in that regard. It is impossible to code in LabVIEW without wire bends so I just quit worrying about it. I do try to limit the number of bends to two at most.

Since it is just not possible to avoid wire bends with or without icons that argument doesn't go very far. The only things I know of that you can wire a vertically compressed stack of small control terminals to without wire bends is another stack of indicators or bundle/unbundle by name. You can't wire them straight to adjacent subVI terminals except in one ironic situation. If you deselect view subVI as icon and drag down the nodes so it looks like a bundle by name or more accurately like an express VI. How many people knew you have the option NOT to view a VI as an icon? Does anyone do that?

As for quickly identifying if it is a control or a VI, well they just look like controls and I can immediately tell by where they are located. You just get used to a particular style after a while I guess and anything else just looks weird and wrong.

There are two situations where I regularly show small terminals. If there is a reason I need to put the terminal in a loop or something or if it is not on the connector pane then I do not show it as an icon. I don't know where I picked that up and just realized that's what I do.

Small terminals are almost required when using an FPGA read/write control node with several controls. It could be useful to have RT code default to non-icons.