Indicate that array constant contains more elements than currently visible

[SteenSchmidt]

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

[Manzolli]

I like the idea of having an indicator of hidden elements and a way to go to the first and last element of any dimension. A right click in the desired dimension to pop-up a context menu with these options would do the job. This may work both in FP with controls and indicators and BD with constants.

[Norbert_B]

Kudos for the idea, i like it very much.

@Manzolli: First and last element is already available very similar as you point out. Rightclick the dimension indicator for opening the context menu, browse for Advanced >> Show Last Element. The first element is always found at index 0 for this dimension.

@Steen: Any idea how your suggestion works with multi-dimensional arrays? How could the user see which dimension is not shown to the last element?

Norbert

[SteenSchmidt]

@Darin.K:

You cannot tell from the visible scrollbar if the array constant contains more elements than currently visible, thus it won't work to solve my problem; namely that you can wrongly get the impression that the array constant you're looking at on the BD only contains the number of currently visible elements. The scrollbar simply does not work for this. IMO you shouldn't be putting a parameter like the number of elements into the label of a constant either, and I think it would be better to get an automatic indication of something that you otherwise would have to include a free label for.

I believe it's important for not misunderstanding the program to indicate that there are more elements in the array constant than currently visible, at least in those cases where the program flow depends on the number of array elements. The visual cue itself could be something else if you have a suggestion, but I think it's important. Hiding array elements can be just as bad as when a structure is shrunk to hide code.

@ Norbert_B:

Multiple array dimensions, especially above 2, are a bit difficult. Here's an attempt at alternative graphics that does not use up any more BD real estate than the current arrays:

The alternative graphics use the same gray color as the typedef triangle. I'm not sure the third dimension (of the string array to the farthest right) needs to be highlighted anymore than it currently is? The argument being that anything above 2D can never show all elements at the same time anyway, so here you'll always have to be careful. But a counter argument could be that it is important to know if that dimension has size 1 or more than 1 (which then should be indicated).

Suggestions and comments?

/Steen

[Norbert_B]

What about adding the "additional element" notation to the dimension index display? Works the same way regardless of the amount of dimensions....

Norbert

[SteenSchmidt]

I thought about that, and it might work even though there isn't much room in those graphic elements. The only problem is that the index display can be hidden from the context menu. It wouldn't be wise to do so as an array constant without index display can be quite confusing.

/Steen

[Norbert_B]

Another question is if this is limited to block diagram constants or should it also refer to front panel array shells?

Is it a feature which can be toggled as "Visible Item" by the context menu?

Great ideas require clarification questions 😄

Norbert

[SteenSchmidt]

Oh, a long post lost due to "authentication mismatch" upon submission. A much shorter version on the rebound, please comment, agree, disagree, suggest etc.:

1) I prefer the new glyph myself  over my original suggestion ; The new one is smaller, it holds more info, and it doesn't look so much like a drag handle. Since the new "more elements" glyph does not enlarge the graphic it would behave better when loading old code into a new LabVIEW version that implements these glyphs compared to a glyph that enlarges the BD footprint of the array constant.

2) I prefer hidden data for columns and rows be illustrated within the array's data field exclusively (with up to 4 gray borders), never in the index displays:

3) The dimensions beyond column and row in multidimensional LabVIEW arrays are usually called "pages". I think it'd be a good idea to indicate additional pages available with a glyph as well. In this case it will suffice with a single glyph in the page's index display, as there can only be one direction there is hidden info in (up):

The "more pages" glyph should probably disappear when you reach the top end of that page range:

4) I don't think one should be able to turn off this feature, as it's not possible to turn off the typedef indicator either for instance. It would undermine the trust in these glyphs if they are there sometimes, and at other times they are not (depending on the whim of the original programmer). If they aren't worth to have on all the time, then maybe their design is wrong or they shouldn't be implemented at all.

5) There definetely should be an explanation for each of these glyphs in the context help when hovering over them. Generally I think such info is lacking somewhat in the LabVIEW IDE (although it's getting better).

6) This visual aid might be valuable for array controls and indicators as well, when they are filled with data. It could look like this for instance (let's consider it for a moment):

/Steen

[fabric]

Steen: I appreciate all the refinements but I think the new assortment of glyphs is starting to look a bit messy. (I initially thought that Darin's comments about visual noise were a bit extreme but perhaps they were just prophetic?!)

Anyway, here's my position:

• I think a glyph to indicate hidden elements is a great idea (although I don't really "love" either of the ones you suggested... )
• I'm not convinced that we need a glyph for each dimension! Surely knowing if there are any hidden elements in any dimension would be a good balance beteeen functionality and visual noise? Anyway, I'm guessing this feature would be of most value in 1D (e.g. array of sequence steps)...
• I also agree that the glyph should be always on, which is another reason to keep it as discrete as possible.
• I'd suggest using something like the typedef glyph, but in the bottom-right corner of the array body. I'd prefer red (i.e. "warning", in line with this) but I'd settle for black...
• I'd leave the index area alone.

[SteenSchmidt]

@fabric: After a bit of thought I actually agree with all your points, with these comments:

•  The latest incarnation I presented seems far too busy when I look at it some more. A simple "here be tygers" glyph should suffice with minimum noise.
•  Red is probably a no-go, as no BD element may be red according to Stephen (obvious exceptions are loop conditional terminal and coercion dots).
•  I think it'd be weird if it was similar to the typedef glyph, just at a different location. People would mistake those two indications.

So how would such a glyph look like? What would you really love?

/Steen

[fabric]

What I would really love is for Labview to completely overhaul its front panel graphics (this would be a good start), to find some way to unload classes from memory at run-time, and to allow us to dig into the C code when we reach the limits of the G... But that's another topic altogether! 

Anyway, I thought it would be good to see how the typedef-ish glyph would look. 

I may be biased, but I actually like them! A few comments:

• I still prefer red over black. I know that the official word from NI is that we should avoid using red on the diagram, but surely that is just so they can use red for these kind of warnings/indicators.
• I definitely like the lower-right corner. After all, that is where I would need to drag to see the hidden elements.
• I take your point about similarity to the type-def glyph, but I think the opposing location makes enough distinction. That said, the black glyph is probably too similar and may confuse some users...
• What do people think about the contrast of the red, especially on pink??