Hide Non-Class-Specific Property Node Selection Menu Options

[KeithTK]

If I've just wasted time digging through the ridiculous class selection menu, why do I have to waste more going over all the less specific properties?

It is particularly painful when having to scroll to items off-screen, and do it multiple times for nested options.

Hide the higher level stuff!  Put it in a menu with a better name than I could come up with or at least hide it with an expandable arrow.

These menus need way more improvement than this, but for a step-1 this is easy to implement, I hope. 

[RavensFan]

At least spell "Class Independent" correctly on the menu!

[KeithTK]

Doh!  That what I get for not spell checking my graphics.

Thanks for catching that while I could still edit the idea

[GregSands]

You could put each grouping of properties or methods into its own sub-menu which has the appropriate class as its name. i.e.

Generic -> ...

GObject -> ...

Control -> ...

and so on.

The only issue might be forgetting which section a particular property/method is in.  Now if we could just type some letters...

[AristosQueue (NI)]

Those aren't less specific methods. They are all methods on the specific class. Whether a class gets those methods by inheritance or by direct implementation makes no difference as to whether or not those methods are available on the class.

You're talking about "digging through the class selection menu". That's one use case. The other use case is I just create a reference to a control or other object. At that point, the method I need often is one of the inherited methods.

Personally, I feel the menus are more than correct as they stand. Moving them around for one use case just makes things harder to find. That's my opinion as a LV user. It should not be read as a pro or con vote for this idea from R&D.

> Now if we could just type some letters...

There are various ways to do that, but the menus are most often useful when I don't know what method/property I need, so any pull-rights just make things harder for me to find what I'm looking for. Again, that's my personal experience, not a usability tested evaluation of users in general.

[GregSands]

But I think the point that was made was that the most often used properties tend to be those towards the bottom of the menu, and scrolling is slow.  Certainly I find this to be true, especially for setting up graphs (which is the example given) - scrolling adds 2-3 seconds to finding a property at the bottom of the list, even on a 1200px-high screen, and the mouse has to be carefully positioned to the scroll bar, and then each sub-menu.

Of interest, does NI collect any metrics on LabVIEW UI use and speed?

My preference would still be for the Intellisense-type functionality (as the Class Browser is really too cumbersome to be usable), but making the right-click menus easier to use seems a good option too.

[AristosQueue (NI)]

> But I think the point that was made was that the most often used properties

> tend to be those towards the bottom of the menu, and scrolling is slow.

If you've got evidence, I'd like to see it, but the numbers I get when running a scripting analysis over VIs would suggest otherwise. Things like Bounds and Label tend to dominate in the controls hierarchy, for example. I'm only checking the VIs I have on my disk, so it's a pretty biased survey, but that's one data point.

> Of interest, does NI collect any metrics on LabVIEW UI use and speed?

Yes. We've done static analysis on VIs as they pass through our hands for years. In 2011, we started an opt-in program for some of our toolkits to proacively send user info in from the field. In LV 2012, we expanded that to core LV. In LV 2013, we greatly expanded the types of data that we can collect (like menu items that are used frequently). We do NOT -- repeat DO NOT -- collect any information sufficient to reconstruct any block diagram or front panel. We don't pull any string text or formulas from VIs. We are very aware of the proprietary nature of the code you folks write using LV. Please do opt in to the program when prompted in LV 2012/2013 to send user information back to NI. It really does help us.

[garrettmarsh]

---

...scrolling adds 2-3 seconds to finding a property at the bottom of the list, even on a 1200px-high screen, and the mouse has to be carefully positioned to the scroll bar, and then each sub-menu.

---

Cool trick: the mouse scroll wheel can be used to navigate these menus as long as the cursor is within the list. You don't have to hover over that tiny arrow to scroll. I find this tremendously helpful, especially for really long lists such as graph properties.

[GregSands]

---

Cool trick: the mouse scroll wheel can be used to navigate these menus as long as the cursor is within the list. You don't have to hover over that tiny arrow to scroll. I find this tremendously helpful, especially for really long lists such as graph properties.

---

  Thank you!

[KeithTK]

@ AQ

Perhaps the idea isn't clear enough as posted.  My intention is not to re-arrange the organization of the menu tree for this or any use case.  The hierarchy is fine (I can find what I want easily enough) but the layout is what could improve so I can reach the desired selection quicker and without scrolling a menu that's taller than my screen.

The properties are already grouped between separator lines based on the originating parent class.  This already contains the class hierarchy, they just are not labeled as such.  Do not change this, but make it collapsible.  The example graphic might be clearer if it showed the top level like this: 

Generic      >>

GObject     >>

Control       >>

GraphChart >>

GraphChart >>

Using chevrons instead of arrows makes it clearer.  Clicking, for example GObject would not move to a new menu level but rather display this:

Generic>>

--------GObject--------v v

Bounds       ->

Master Bounds Rect

Position      ->

Selected

Total Bounds Rect

UID

------------^^----------------

Control >>

GraphChart >>

GraphChart >>

I would even argue that your use case benefits from this too because it provides visible knowledge about the class inheritance that many users don't remember off the top of their heads.

I chose this specific example to point out one point that should be renamed or rearranged since two levels have the same name.  The only other problematic issue might be if there was a class hierarchy level in the chain which has no inherited properties for the current class; It hides nothing within it's grouping, should it be left out, grayed, expand to 2 separator lines maybe say 'empty' in between?

Chevrons have at standard behavior (at least in practice) and are common enough not to add a learning curve.

If you want to get advanced:

1) Implement some intelligent way of different use cases having one inheritance level expanded already when first displaying the menu. I'd expand the lowest level by default but that may not always be the most useful.

2) Chevrons do not require a click but rather 'peek' and expand on a momentary hover, then collapse if the mouse leaves the expanded section before making a selection.  It's also pretty common behavior.

And while I really like the idea of "start typing the name to jump to it" (like windows 7 start menu) I dislike an right-pulls that move my mouse for me or place the focus away from the mouse.  Windows avoids this by using a specific search box, if the name displayed in the property node could act as that search... I think there is alrady an idea for that

[KeithTK]

Hmm, my mouse scroll doesn't work on menus in LV2012.  This has always annoyed me but I figured it was universal.  

Considering the poorly inconsistent way mouse scroll wheel is implemented by just about everyone in general I shouldn't be surprized.