Jump to content

Feelings on Icons for Terminals?


Recommended Posts

I was just reading some opinions on NI.com about whether it is better to show FP terminals on the block diagram as full-sized 32x32 icons or as the smaller 16x32 terminals. I wondered what people on LAVA think. Do you use one type or the other and how strongly do you feel about it? Personally I (moderately strongly) prefer icons.

-- James

Link to post
Share on other sites
  • Replies 74
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Wow, guys, make drjdpowell feel bad, why don't you?

This is one of the first default settings I change. I think icons on the block diagram are unnecessarily large and provide no additional value over the terminals. You're actually the first I've (know

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

Posted Images

Definitely the small terminals. I remember when I first took an NI training course (running LabVIEW 2009 I think) and saw all these huge terminal icons. I had been using LabVIEW 7.1 exclusively up to that point, and didn't know what they even were at first. Like asbo, one of the first things I change when I do a fresh install.

The only case that I've seen where they provide something extra is they display whether you have a chart/graph indicator or just a "plain" array or waveform indicator. Still not enough to make me use them, but it's something...

  • Like 1
Link to post
Share on other sites

Oh dear, 5 to 1 against so far. Surely there are some more unicorns?

Additional question (motivated by the ni.com discussion): do you think having both forms leads to confusion, and would you be in favor of LabVIEW being changed to allow only one form? For the purposes of this question, assume the form to be chosen is the other one from the one you like.

-- James

Edited by drjdpowell
Link to post
Share on other sites

Just wanted to chime in and put a vote in for non-icons. Again I've never known anyone to prefer them.

I don't use express VIs often, but when I do I always change them to the icon view and remove the caption. Probably to save on block diagram space.

Link to post
Share on other sites

Just wanted to chime in and put a vote in for non-icons. Again I've never known anyone to prefer them.

I don't use express VIs often, but when I do I always change them to the icon view and remove the caption. Probably to save on block diagram space.

+1

The only time I see icon terminals are when someone new to LabVIEW starts programming, but then it is only because icons are the LabVIEW default.

/J

Link to post
Share on other sites

I usually use the small terminals, although I'll sometimes use icons for typedefs (because the typedef's icon is shown). This works equally as well for cluster icons on the BD that are typedefs. So I guess you could put me down for my usual "it depends" half vote yes, half vote no.

Link to post
Share on other sites

I hate large icons. Aristos Queue loves them. If I had my way, they would have been gone long ago. Unfortunately, AQ always argues to keep them around. But since he's so badass in just about everything else he does around here, I'll pick my battles elsewhere. ;)

  • Like 1
Link to post
Share on other sites

If I count right that's 9.5 to 1.5 (2.5 if you count AQ).

Let's look at one of my more recent subVIs:

post-18176-0-84452700-1319643931_thumb.p

I choose this one because it has 8 total controls/indicators, which is more than most.

The first thing this illustrates is that I use a lot of LVOOP objects, of more than one type, and a little thing that says "OBJ" really isn't that useful for easily identifying the object.

The second thing is that in subVIs, the terminals are all (or mostly) the inputs and outputs of the VI, and I place them on the outside, with plenty of space for a larger icon. Even if the icons were just bigger versions of the smaller terminals, I would still consider them superior, because inputs and outputs should stand out and draw the eye.

This example also shows what is probably the highest density of Front Panel terminals on any of my VIs. My User Interface VIs tend to use event structures and subpanels and a relatively small number of "big" controls/indicators. "Big" in the sense that they do a lot, like a Multi-column Listbox with an extensive list of Right-Click Menu options, or a Text box that holds a summary of a large amount of information, or an Xcontrol. So I seldom have a need to pack controls in densely. In fact, the terminal icons are sometimes just sitting, unwired, near the event structure, acting more as graphical documentation than actual code. This documentation is important, because most UI control/indicators are major parts of the VI, and I want their presence to stand out on the diagram.

To be devils advocate, if your fighting for space to fit yet another not-very-important indicator nested somewhere deep in a tight diagram, then your not coding as clearly as you could. :)

-- James

Edited by drjdpowell
Link to post
Share on other sites

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

1) They are easy to see. I am very focused on the interface and I want the terminals to stand out.

2) They sometimes contain additional information, and I consider them more aesthetically pleasing.

3) Saving space is not a concern because of the way I design my applications. A class method (and very nearly all my VIs are methods in classes) usually has the terminals for the owning class, error terminals, and maybe an additional input or output (occasionally a couple of each). I have plenty of room for these on the block diagram, and I want them to be highly visible.

  • Like 2
Link to post
Share on other sites

If I count right that's 9.5 to 1.5 (2.5 if you count AQ).

Let's look at one of my more recent subVIs:

<snip>

To be devils advocate, if your fighting for space to fit yet another not-very-important indicator nested somewhere deep in a tight diagram, then your not coding as clearly as you could. :)

-- James

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 :)

  • Like 1
Link to post
Share on other sites

I always enjoy this discussion. First of all, no need to feel bad for James. If you follow the other discussions, you know if anything happens he will have the last laugh.

If you have OCOOD (obsessive compulsive OO disorder), then it is likely you also suffer from I-have-two-primitives-wired-together-here-better-create-a-subVI syndrome. This results in a lot of time spent with the icon editor and plenty of whitespace to fill with terminals. I do not mind the iconified terminals so much in that case.

Most times I worry more about blazing speed than reuse, so I have a dense coding style. My biggest problem with the icon view is that they take a lot of space and give little information back in return. Do I really need to see a little stop button icon when I am wiring to a boolean labelled Stop?. The exceptions are XControls, Graphs and Charts, I tolerate icons for those (when I give a darn, which is not often).

I don't use express VIs often, but when I do I always change them to the icon view and remove the caption. Probably to save on block diagram space.

I once submitted an idea to provide an option to de-Expressify the Express VIs so I could drop them in peace (no popup, icon view, no caption) but it was shot down in flames. Fortunately I only use two of them so I settle for Merge VIs on the palettes.

Speaking of Express VIs, I will say that I see more use in the Block Node View of SubVIs than I do in the Icon View of terminals. Of course by that I mean epsilon > 0.

Edited by Darin
Link to post
Share on other sites

If you have OCOOD (obsessive compulsive OO disorder), then it is likely you also suffer from I-have-two-primitives-wired-together-here-better-create-a-subVI syndrome.

Nope. That's the ARCLD (Analy retentive classical labview disorder). Those with OCOOD have to create a class project, sub-vis for all the methods and fill out a multitude of dialogues.

Link to post
Share on other sites
The first thing this illustrates is that I use a lot of LVOOP objects, of more than one type, and a little thing that says "OBJ" really isn't that useful for easily identifying the object.

*Exactly*! If the icon shows something useful (other than just the datatype, which is shown on the terminals anyway) then it's often appropriate to show the icon.

Link to post
Share on other sites

Terminals, definitely. It's one of the handfull of settings I immediately change with a fresh LV install. (Along with branching dots, constant folding, and a few others.)

...because inputs and outputs should stand out and draw the eye.

I disagree. 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.

When I look at the diagram you posted it's hard to quickly identify where the vis are. The first couple times I glanced at it I didn't even notice the final Msg method outside the case structure--it was lost in the noise. In contrast, I easily identified all the sub vis in Shaun's diagram.

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By LogMAN
      So this just happened to me and I'm quite confused by it. As it turns out, the .NET Constructor Node not only provides terminals for error in, error out and the reference, but actually two more "hidden" terminals:

      Notice: I left the error terminals untouched and none of the wires are connected (try it yourself). This never occurred to me. Only now, while hunting a null reference exception I found the constructor node looked "off", like this:

      The strange part is that the terminal doesn't actually carry the reference (which is why I receive the null exception). It only specifies the type. The upper left terminal is a void type input, so the wire is always broken.
      Does anyone know why these extra terminals exist? They don't seem to be part of the specification as far as I can tell.
      Any fancy things we can do with this?



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.