Easy access node configuration (auto-menu)

[SteenSchmidt]

Hi,

I think there is too much clicking around in the BD to enable/disable/configure node options. I'd like some sort of context sensitive menu that just automatically appears when you hover your pointer on top of any object in the block diagram. For instance when you right-click the Read from Text File primitive you get this context menu:

You can do a lot of things here it seems, but there are actually only 4 direct configuration points, namely the ones I've highlighted with a red dot. It'd save a lot of right-clicking and subsequent menu browsing if a configuration menu just appear when you hover over an object for a short amount of time (50 ms maybe, the exact delay must be figured out by the UI guys):

  Hover for a fraction of a second...

  ...go ahead and configure the node.

a) The node configuration menu may not cover any of the object itself, thus you'll still have access to the entire object graphic if your purpose was interaction with that.

b) No menu should appear unless your tool is empty. No need to make the node configuration menu appear if you approach the object with a wire for a terminal for instance.

c) Advantages are (at least) no mouse-clicking necessary, no menu fly-out hunting, no grayed options that takes space, no duplicate/triplicate options that takes space, no configuration dialogs that doesn't add anything extra (how about all those Properties dialogs that just lets you edit the object's label in a fancy way, but you have to look, because a new property might've been added in this LabVIEW version?). Just an intelligently populated menu with only the configuration options that makes sense in this context.

d) Help text for each configuration item should be shown in the context help window when you move over each item in the list, possibly minimizing the need for opening detailed help.

e) The short delay from still pointer to menu emergence means you can still move your pointer around the BD without menus flying about everywhere, while the delay is small enough that the menu seems to appear almost instantly when you do hold the pointer still on top of an object.

I envision such a node configuration menu to appear for any node basically. One of the key aspects being that the menu is object and context dependent. For instance a subVI:

... or a tunnel on a While loop:

For some objects there might even be some key information available in this node configuration menu, information that is otherwise several clicks away. For subVIs such information could be if it is inlined, reentrant, has debugging enabled etc.:

Cheers,

Steen

[GregSands]

Once again, your graphics are excellent.  I was thinking this reminded me of some other idea - went looking, and it was another of yours: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Quick-subVI-configuration-and-overview-from-caller-BD/... I think I prefer this current idea over the older one both style- and content-wise, even though they could be made roughly equivalent.

[fabric]

You got my vote with "context sensitive". I think that is the key to giving these menus the right balance between function and form.

[Jokelnice]

Right, it's a good idea, also eg "Visible Items \ Label" is widely used, and there are two steps to do to use it.

[JB]

Nice idea. This must be implemented in such a way it will not open the door to unwanted changes !

[SteenSchmidt]

@JB: Could you elaborate a bit on the "unwanted changes" part?

/Steen

[SteenSchmidt]

Actually, since the node configuration menu should be context sensitive, the above inlined subVI should have this reduced menu instead (just for completeness sake):

/Steen

[fabric]

Question: Should the context hover menu auto-hide after a short time? A few possibilities are:

1. vanish when mouse pointer leaves the object
2. vanish on demand (e.g. ESC key)
3. auto-hide after some delay (e.g. 3s)
4. any/all of the above

I think my preference is for 4, with the following caveat: It would be nice to be able to manually show the menu if it hides itself via a hotkey. It always bugs me in MS products when the hover menus disappear before I want them to!

It would also be very useful if the menu was keyboard-navigable (e.g. up/down arrow keys and space to toggle, press "L" to toggle Label, ...)

[SteenSchmidt]

I think the menu shouldn't time out, exactly for the reason you state yourself; it's annoying when you study a menu and it disappears before you've made up your mind. The needed time varies from person to person and from situation to situation. Sometimes it must stay on for a long time if you fiddle with a screenshot utility, if you are explaining something to someone, or simply if you leave for lunch and want that menu to stay on as a reminder for when you get back.

But 1 & 2 are both great IMO. The menu should disappear on ESC and when you leave the object (probably when you leave the menu outline in any direction, albeit with some leniency to not disappear just because you for a nanosecond touched the first pixel outside the menu border - but that's something for the UI guys as well).

Should probably also be enableable/disableable in LabVIEW.ini as with all other new features.

/Steen

[kegghead]

Excellent post. However I worry this would have a negative effect on useability. I can only imagine trying to select a node in close proximity to another only to have the context menu automatically appear and obscure the node I was originally trying to select. Worse if it appears after a timeout just as I click and I then go about making some change without knowing what I've changed. If you then put a longer timeout such that this is less of an issue, chances are I'd just right click because I don't want to wait for the timeout. Not ideal either way.

Regardless, what I really like is the idea of having easy visiblity for things like inlined, Open FP when loaded etc. I really don't like how these properties are burried out of site and not obvious on the block diagram. This still won't show it in code unless you interact with the diagram, but it does make that info more accessible.

[SteenSchmidt]

About usability/accidentally activating such a context menu by proximity:

My coding style is aiming at placing every BD node with a spacing of 8 pixels - for instance like this:

Terminals are usually located closer to the edge than towards the center of most BD nodes, or you at least approach the terminals from the edge, so it's probably a good usability advice to keep this most active area free from activating the node configuration menu. I think the menu activation area should be centered around the middle of each node, like this (if you hover for a short while in the dark blue area the menu activates, you need to hover in the light blue area a bit longer to activate the menu, and hovering in the gray area does not activate the menu):

The above, combined with the delay before activation which lets you pass the pointer over a node without activating the menu as well as the fact that no activation can happen at all if you are dragging anything or have the paint tool selected, will hopefully make it easy to figure out when the menu gets activated and how to avoid it if you don't need it.

Note: The node configuration menu never overlaps the node itself. Therefore even if you hover at the center of a numeric constant for instance, meaning to edit its value, and the menu appears, you just click and thus edit the numeric value as you'd do right now. The menu should then disappear the moment you start the edit making the exact same workflow possible as today.

Also, the remedy for not accidentally manipulating the values in a popup menu is to first activate the menu items a bit after the menu itself appears. Humans typically react in about 50 ms. to such a menu appearing, so if a delay of 50 ms. exists between the menu appearing and the selection glyphs becoming active that will let you realize your mistake and probably eliminate all mis-selections. The extra 50 ms. isn't wasted, as you have to move your mouse down into the menu anyway - and that should hopefully take longer (or else the inactive-time must be shortened, because it's even worse to have to push twice on a selection for it to catch).

Most of this is standard UI dynamics and NI is more than capable of figuring this out to work seamlessly if they choose to implement this feature.

/Steen