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

[fabric]

---

@kegghead wrote:

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

---

Fair point. This is always going to be the tricky thing to get right with such a feature...

Might I suggest a global toggle (much like context help)? Toggle on context hover and you can make all the quick config edits you want. Toggle it off and you can get back to connecting wires.

[SteenSchmidt]

I feel that having to enable/disable such a feature, as with context help, would take much of the value out of it. It should be a configuration interface that's immediately accessible when you need it. If you have to first activate it then use it, you might as well use any other modifier key or right-click the node anyway.

I don't think it'll be a problem accidentally activating these menus. Today you have no problem selecting to watch context help for a terminal (wire) vs the node itself. It's second nature to place the cursor just where you want it.

Anyways, the best way to find out for sure will be a field study. Since we don't have public IDE events available I can't implement this in LabVIEW directly, so I'll have to do fake something. I'll see if I can find some time to try this out myself, but it'll take some effort just to make a "fake" demo.

/Steen

[Underflow]

Tossing in a negative here: I, personally, *loathe* hover menus.  They conceal other parts of the UI, and always seem to try to "help" me when I really don't need it.  A UI should respond when I give it intentional input.

Most of the example items will need to be set only once, and then I never, ever want to see that menu again.

I would be much more okay with it if I could control when the menu would appear by, for instance, mousing over with the control key pressed.

[Daklu]

I don't hate hover menus to the extent Underflow does, but I do find they get in the way more often than they help.  The palettes are a good example.  If I pause on a subpalette for too long it opens up and obscures the next item in the original palette.  Bleh--annoying.

I like the general idea, but would favor a Ctrl-right click to activate it.

[SteenSchmidt]

Resistance to this I feel, hmm...

Ok, I also hate automatic emerging stuff that gets in the way of what you're actually doing. That is why I described these two requirements:

1) If you're doing something else than just moving your mouse around, this menu does not appear. That "something else" could be if you're hovering on a terminal of the node, or it could be if you're carrying a wire in the wire tool for instance. In such cases the IDE should be smart enough to not present this selection menu to you.

2) The emerging selection menu does not cover any of the object you're hovering over, so you're still free to interact with the object itself if that was your intent (say you wanted to move the object or just see its context help for instance).

Both of the above makes this feature stand apart from the horror scenarios you describe with popups. Both of those should actually be features of most if not all existing popup menus out there, but sadly aren't.

Second best would be a CTRL+right click (or CTRL+hover) to activate, but that's still one keystroke (or one keystroke + one mouse click) thus merely a slight improvement to the existing context menu.

What I try to suggest here is a much more clever IDE that presents you with the options you want, instead of making you hunt them down which in turn requires you to know in advance which options are available. There are too much mouse clicking going on in the LabVIEW IDE, it should be possible for the IDE to deduct much more of our intentions based on our recent action history. That's basically the direction UI development is moving - it's called Context Aware UI, and is part of the Responsive Design movement.

That, and the fact that too many primitives (all objects really) have options that are safely hidden for years. How large a percentage of the user base discovers instantly when a new option appear deep in the context menu of a string-prim for instance? Sometimes it takes years before you stumble upon some timesaving functionality that was introduced, but means you must delve a couple of levels into the context menu to set it. With this idea you see that new option instantly in the selection menu the moment you drop that prim into your BD. New options could even be highlighted for a while. But the prime feature is that there is only one level to this selection list, and that it only contains 'configure items'.

/Steen