LabVIEW Developers Feature Brainstorming

cancel
Showing results for 
Search instead for 
Did you mean: 

Node configuration consistency

Highlighted
The LabVIEW block diagram is a set of nodes with wires connecting them. Ideally, this would completely describe the functionality of a block diagram. But as LabVIEW has developed, some nodes have been added that need 'configuration'. For these nodes, their behavior is not completely defined by the wires connected to them. Here's a rough list (not complete) of some of the ways nodes are configured:
  • Using popup menus (such as the "Compare Aggregates/Compare Elements" setting on the comparison functions)
  • Using dialog boxes (all the various Express VIs, the Event structure)
  • Using menu rings (the Polymorphic VI selector)
  • Using text entry (the Case structure ring, the Expression node)
  • Using clicks on elements of the node itself (the Invoke and Property nodes)
There are others more arcane.  Some nodes use a combination of methods.

The long and short of it is that a number of users have reported going for years without discovering that a given node has settings. I have been toying with an idea for a while to bring some consistency to this melange.

What is needed is two-fold. First, nodes need a standard way to indicate that a given node may be configured. Second, the nodes need to have a standard way of getting to that configuration. They may have alternate ways of configuration -- shortcuts that work for a particular node -- but for those who haven't discovered the shortcut, the config needs to always be accessible in "the standard way," whatever that turns out to be.

Now, to sidestep one tangent issue: Many folks want the configuration for a node to be entirely determined by wiring, be it constants or other nodes. This is for two reasons:
  • readability of the diagram and for printing VIs, so you can always study a diagram and understand what the functions are doing and
  • runtime/scripting configuration of the node is possible
Configuration by other means is going to happen on future nodes -- a dialog or popup is better than wiring constants for many complex nodes.  I'd like to keep the discussion focused on how to present this cofigurability and less on whether or not configuration is appropriate. I happen to agree with the position that if a node is configurable then something about its draw style should indicate how it is configured.
(continued in part 2)
Message 1 of 11
(13,274 Views)
Highlighted
(continued from above)

Indicating Configurability
The Express VIs use the blue halo to indicate that they are not standard subVIs -- if you double click on them, you'll get a configuration page with options. When I first saw this halo idea, I thought it might be nice to use for any node with configuration options. But I have slowly come to the realization that almost every node except for a handful of primitive functions can be configured. Some of these configurations -- such as the options on a subVI node -- are very rarely used. But they exist nonetheless. The Express halo would be less useful if it suddenly appeared on every node. This would be true of any simple draw style or glyph.

Now, the glyph might be useful if, instead of a halo, that glyph was the spot you clicked on to perform the configuration. Perhaps a small drop arrow or star that lets a user know "click here and you can change how this node behaves."

The other option I can see is a popup menu item akin to the ever-present "Properties..." that appears on front panel objects. Any node that has configuration would include this menu item when you right-clicked on it (or the key+click action Macintosh folks use).

Are there other ways of presenting node configuratbility? Is there a preference among the options I've presented?

Performing Configuration
To some extent, how you perform the configuration is determined by how we indicate it. If we have a glyph that indicates configuration, then clicking on that glyph would be how you would perform the configuration. Similarly, if the indication is the presence of a menu item in the popup, then selecting that menu item would allow for configuration of the node.

But what happens after that? Obviously, the Express VIs need a full dialog to appear for their myriad settings. But a dialog may be overkill for some options. Take the menu ring on Polymorphic VIs. This is used to select instances of the PolyVI when the instances only differ by output terminals. When the user clicks on the glyph or selects the menu item, should a dialog appear? Or could we simply make the menu ring visible? This is a question of consistency versus usability. If every node brought up a dialog, there would be a consistent way to setup every node. We would sidestep the problem of a user staring blankly at a menu ring wondering, "Ok, what do I do with this?" On the other hand, for so simple a configuration, showing the menu ring would allow a user to quickly reconfigure the node, which in this case might be more usable than launching a dialog every time they wanted to change which instance of the PolyVI was selected.

Is the consistency important? Could we possibly have two behaviors (slightly inconsistent, but a node would either show a dialog or show X, where X is some simpler, lighterweight way of configuring itself)?

Side Issues
Originally, I was persuing the idea of "double-click to configure."  A glyph or halo would indicate that a node was configurable, and double-clicking would show the configuration. Double-clicking on a plain subVI would open the subVI, just as it does today. That was, to me, configuring the node. All the other nodes (built-in functions, Express VIs, etc) would open some config dialog as appropriate. But then I realized that the individual subVI calls can have configuration, which muddied that idea.

Whatever idea is suggested needs to work as well for small nodes as for large nodes and structure nodes. Remember that the goal is to guide a user to be able to find these configurations to cut down on the number of, "I've been using LV for X years. I didn't know that node did that!" posts to DevZone. 😉


Message 2 of 11
(13,264 Views)
Highlighted

People will never know that the options exist. So many features are added to LV in each version that it becomes impossible for experienced programmers to notice small additions to various functions. The subVI node setup you mentioned, for instance, is something I almost never notice - my brain simply edits it out of a subVI's pop up menu.

This is basically connected to the context sensitive help topic you brought up way back - can we get LV to draw attention to properties which would otherwise go unnoticed without being annoying?

As for creating a standard way to access properties, there already is one - "when in doubt, right click". It is likely that adding to this (not replacing) a properties page for each subVI will help - maybe users which will miss some of the information available in the context menu will notice it when it appears in a separate dialog window, especially if new features are highlighted.

As for the configuration appearing on the BD - I'm not sure whether I would want configuration information for subVIs cluttering up my diagram, and I'm not sure how much you can actually change the configuration at run time (many options, like the aggregate comparison you mentioned, are design time only), but I never really used express VIs or timed loops, for instance, so I'm not sure about this.

Just some ramblings so far.


___________________
Try to take over the world!
0 Kudos
Message 3 of 11
(13,230 Views)
Highlighted
Hi,
 
I think it's rather annoying that you have to click on something to see what it is doing. This goes for sequence structures (so should be used only for synchronization), case structures (can sometimes be replaced by a switch function) and most of all express VIs. It does _not_ go for the nodes where you can still see what's happening: comparison with aggregate, the universal AND/OR/PLUS function, property node etc. They only require clicks for configuration.
 
It simply makes the diagram so much more readable if you can see what' shappening. I fully agree with "when in doubt, right click".
 
You say that we should expect things to get more dialog configuration. But this also means the selected behaviour of functions cannot be determined by things like input clusters anymore. That would be really sad. It would flatten LabVIEW's flexibility. You would need to use a case structure to select from three dialog-selected behaviours of the same function, while now we can select the behaviour by just changing an element of a cluster that goes to the function.
 
I would be in favor of more autogenerating code for novice users, though. They would learn how the function works and the diagram remains readable !
 
Joris
 
0 Kudos
Message 4 of 11
(12,959 Views)
Highlighted
What about presenting vi's which has configuration options with a 3D look. This would indicate that there is a third dimension of connectivity.
 
regards
henning
0 Kudos
Message 5 of 11
(12,935 Views)
Highlighted
At first I thought a 3-D concept might be interesting, but considering the number of primatives that have configuration options, the block diagram would become harder to read and probably awful to print in black and white.

A glyph placed on the node might be a problem because many of the primative functions (e.g. In Range and Coerce) are not standard sized icons. Where would the glyph reside? Would it be floating outside the icon boundries? Ugh.

Maybe a new block diagram cursor type that appears when the mouse is placed over a configurable function (a magic wand? 🙂 This cue to the operator would be context related and not change the look of / complicate the block diagram.

 If a change to a function was new to a particular version of LabVIEW , it might be possible to use a colored or animated cursor to catch the eye of an experienced LabVIEW user that "something is new here". Alternately, the beige background for primative functions is fairly consistant. Maybe a change in the background color or an additional 1-pixel wide outer border (green?!) on mouse-over for configurable functions would work well.

If I load a VI written in an earlier version of LabVIEW, the last thing I want to see is a bunch of "Configure Me Now!" pulsing halos, chasing-lights borders or spinning glyphs. People learn to ignore them, or even block them because they become too anoying. (Think Google Ads or Monster Truck Rally advertisements on the radio)

Subtle, context sensitive indications only please....

Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 6 of 11
(12,845 Views)
Highlighted

Phillip Brooks wrote: <snip> Maybe a new block diagram cursor type that appears when the mouse is placed over a configurable function (a magic wand? 🙂 This cue to the operator would be context related and not change the look of / complicate the block diagram. <snip>
This is great! It would make it invisible to casual observation (looking over someone's code) if you did not want to see it. It would not stand out when printing. It would however, not change the difficulty of not knowing the configuration of a node merely by looking at it (as is a common complaint of the Express VIs).

I like the idea of a change to the cursor, but I am not sure how it would work. If you already use the auto-tool, you have 2 or three different cursors on one node as it is. If you don't use auto-tool, do you really want the visible change anyway?

I do think that this is probably the best idea I have heard here so far, I am just not sure about how it would work.

Bob Young

0 Kudos
Message 7 of 11
(12,828 Views)
Highlighted
Phillip: A perfect example of why to talk to customers! The mouse cursor suggestion hasn't come up before. Thank you!
I'll consider this idea in the next round of brainstorming. Personally I'd still like to see somthing while editing so I know to move my mouse there, but the mouse cursor would encourage the accidental discovery, which is the largest percent of the problem today.

Bob: thanks for the point about printing. If we do add a glyph to the editor, it probably wouldn't be useful to include that in the printout.

-- Stephen Mercer
-= LabVIEW R&D =-

0 Kudos
Message 8 of 11
(12,820 Views)
Highlighted

For me, the old "the diagram IS the code" paradigm is a biggie.  Stuff that requires a right-click to see which mode options are selected are an annoyance, and another potential source of hard-to-find bugs.

When I look at the diagram, I want to be able to know at a glance which nodes may have some additional hidden config options WITHOUT having to hover my mouse over each one individually.  (The magic wand idea sounds interesting, I just don't want it to be the ONLY hint).  Exactly what the visual cue should be is not something I have a strong opinion about, but I'd propose that it be one of the things that can be user-configured in Tools-->Options-->Block Diagram.  Maybe it's a bounding box with a possibility for the user to define the color (like the tip someone posted about making coercion dots bright red to stand out more).  Or maybe a semi-transparent overlay that can be enabled or disabled by an individual user.  I think the key is that people like me that want an obvious visual cue can have one and people who consider it to be clutter can turn it off.

-Kevin P.

 

0 Kudos
Message 9 of 11
(12,818 Views)
Highlighted

I think new features should be very fast to use, but there should always be also an easy way for not so advanced users. However LabVIEW is a daily tool for many of us and therefore the needs of power users should never be overlooked. I conclude my thoughts of configurable nodes with the following list of ideas.

  • The configurability should always be visible on the block diagram, so that it is always evident when the node is configurable. A good candidate could be a rectangle just slightly larger than the node surrounding the node (see image below). It should be small enough not to mesh up with existing block diagrams. It should be transparent to show all the wires behind it. Still it would instantly tell the user if the node is configurable. An item on top of the VI icon may be confused with the icon pixels.
 

  • There should be a new window Node configuration similar to the context help window indicating current configuration of each node when you hover the mouse over the node. The window should also indicate all the configuration options. The user may select weather the window is visible or not. This Node configuration window should not be mixed with Context help window since both windows are useful. Context help window could have a link to the Node configuration window if the node is configurable.

  • There should be an easy and fast way to access the node configuration. I prefer a small black arrow in bottom right corner similar to Photoshop tools window. (See image above). An alternative would be shift + click or something similar.

  • Accessing this fast configuration by pressing the arrow would (in most cases) open a fast configuration window just next to the current mouse position. Fast configuration window would be like Node configuration window except that it would allow user to set values for the configurable properties. Fast configuration should be very simple and very fast to use (unlike express vi configuration dialogs). Is should just list all the configurable properties. No positioning of properties or anything fancy should be possible. Only the order of the properties could be controlled, everything else would be automatically generated by LabVIEW. (see image below)

  • Visually more complex express VI like configuration window could be opened from the context menu if needed. The node could also forbid using the fast configuration window in which case the more complex window would always appear.

  • All the configurations must always be accessible with property nodes or similar for scripting or other programmatic access to the node functionality

  • One must be able to save configurations to the disk and load the configurations from the disk both interactively and programmatically so that configuration process doesn't need to be repeted to nodes with similar functionality. There must be a common file format for the configuration (XML) files.

  • There should be a way to print the configuration of the nodes when printing the block diagram. I suggest that the "Node configuration" windows are somehow attached to the printing as foot note. Use can define how the printing is done.
Tomi
--
Tomi Maila
Message 10 of 11
(12,787 Views)