Consider reevaluating the organization of menu options.

[K_Joy]

One of the major obstacles to LabVIEW adoption is the difficult learning curve (perhaps it’s easier than learning a text-based programming language, but still). A simple reevaluation of whether certain options are in the most logical place might help make it easier for first-time users.

The two that caught me up the most when I was first using LabVIEW:

1. I expected to find the Tools Palette under Tools not under View. This tripped me up a number of times, saying, “Where on earth is the Tools Palette!?” Over the last several years I have observed a number of new users have the same difficulty. If the first place the average user looks for something is not where it is, then it is either in the wrong place or perhaps something is poorly named. The things under Tools may be better thought of as “Utilities” or something so I wouldn't keep looking for the Tools Palette there.
2. I expected to be able to click View>>Block Diagram to view the block diagram, not Window>>Show Block Diagram. Again, you watch someone who is new to LabVIEW poking around trying to navigate and I guarantee they’ll click View before thinking to look for it under Window.

The more I use LabVIEW, the more I find things that just seem to be in weird places. I know this may seem silly, but I think it would be worthwhile to do some new usability studies on things like this.

[tomlawton]

I've been using LV since LV2.0, and I could swear they've moved the tool pallette back and forth- I still hunt for it...!! (No, I don't use auto tool select- "Tab" is what your left hand is for.!)
Not that I often need the pallette- except to turn off auto tool select on others' machines- but I think the only correct place for it is in both menus!

[AristosQueue (NI)]

The Window menu is the Windows OS standard location for all document windows. The View menu is where we put all the windows that are not independent documents. It should be that View contains stuff that doesn't come from File >> Open. So the Tools Palette is in the right place. The Tools Palette is unfortunately named. Before we would move menus, I'd suggest renaming the Tools Palette or renaming the Tools menu. Since the Tools menu is somewhat dictated by the Windows OS conventions, I'd lean toward renaming the Tools Palette. (I wouldn't put it in both palettes if only because that would make the Tools menu needlessly longer.)

Moving the ctrl+E to the View menu seems like a good idea.

[Manzolli]

Like the title. Maybe creating new menus. Fragmenting the Tools menu may help too.

[KeithTK]

@AQ

Why try to stick with OS conventions anyway?  LabVIEW is in no way an OS.  It is a document editor and even MS's document editors follow different conventions from the OS.  Why not follow the convention in things like MS office?  That seems to be the OP's 'expected' reasoning.

[AristosQueue (NI)]

I'm referring to the OS conventions *for applications running on that OS*.

Windows and OSX (and iOS and even, to a much lesser degree, Android) both have established guidelines for all applications that run on that OS. MS Office follows those conventions. So does LabVIEW. Having conventions for applications on the OS makes it easier for users to move from app to app and for apps to interoperate. For example, pretty much every app reserves ctrl-X, ctrl-C and ctrl-V for cut copy and paste. But it is just the OS guideline. Any app is free to choose any combo they want. But by having things consistent, users don't have to relearn from scratch how to use parts of an app.

Just an example of the extensive guidance that MS provides to app developers:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511258.aspx

[KeithTK]

I'm glad there is a reasoning behind the current arrangement, even if it's not what I might prefer.  But if users are experiencing trouble (does the opt-in collection know if I clicked the correct menu the first time or had to search around?) doesn't that suggest that interpretation of the guidelines is inconsistent with common practice?

And this all extends much further than just menu arrangement...

While these surely have other justifications, comparing the reference you provided:

"Use at most three levels of menus" & "Don't put more than 15 items within a context menu" vs.. The property selection tree... lol.

"Don't make commands only available through context menus"  ha ha

Plus many very handy and increasingly common practices listed there than labview could adopt: Context sensitive task pane anyone?

rant

Or is this all an 'average user age' issue and when I say 'common practice' I mean 'modern practice'?  Many aspects of LV have always felt like hold-overs from many years back. After a large gap in usage of labview for many years and versions I was surprised how familiar I was with it... And that is not a compliment.  I was familiar with the things that were always a pain and were still around.  Kinda like windows device manager.  So many jumps to get to a commonly accessed feature, but everyone I know could do them blindfolded.  That doesn't mean they shouldn't improve it.

Indeed I've learned many things truly are hold-overs going back even as far as the mac-only days.  Practices and formats that you could probably not find in any other software released in 2013.  And the current justification for not improving things is often 'user familiarity'.  Which is ok to some degree, but must have an expiration date.  Users were familiar with windows 95 and by that logic windows 7 should look and act exactly the same.  LV users are more adaptable than NI seems to think, and if change makes their experience easier after their complaints getting over a learning curve it benefits everyone in the long term.

There are some brilliant features in labview that were actually ahead of the curve of modern interfaces in some cases (quickdrop rules), so NI is certainly doing something right.  But then why drag their feet in other cases.

Semi related example is spell checking a post. Not knowing words like NI and labview makes me giggle a little.

/rant

[AristosQueue (NI)]

Kieth: We (LV R&D and NI generally) are aware of every point in your post and have regular discussions about what to change and how far/fast, when to follow standards and when to break them, and what LV users will accept and what they won't. And then there's also the category of what we think we can get away with keeping. The R&D team is smaller than most people think, so we prioritize what we work on. Do the menus feel 10 years old? Yes. Are they still usable? Yes, mostly. Do we make them more modern or do we add a new FPGA compiler feature? Some days the menus win, most days the compiler wins. But as I hope folks have seen in some of our NIWeek keynotes, we are looking for ways to move LV in more modern directions and products like Data Dashboard let us experiment with options. We will have more along those lines as the years progress.

Believe me -- we're as aware as any of you about the way that software ages, and we're quite aware that our viability as a business rides on not letting any one aspect of the product slide for too long.