New palette options: 'Open VI' and 'Run VI'

[SteenSchmidt]

Hi

Currently on a functions palette item (when you edit the palettes) you have the option of placing the VI contents as an alternative to the default behavior of placing the VI itself on the block diagram:

I suggest two additional options in this menu: 'Open VI' and 'Run VI'.

Two such options will enable us to bundle help-VIs, scripting VIs and examples directly in a sub-palette of toolsets, instead of going the long almost impossible way of building bin3 files for the Example Finder.

One of many current use cases we have at GPower is the ExpressionTester in our Expression Parser toolset:

The ExpressionTester is a utility, a small application actually, that lets the user investigate different mathematical string expressions before committing them to code, and it has no use as a subVI. We feel it has the highest chance of user discovery when positioned just with the toolset functional VIs (i.e. in the palette), instead of being buried either on disk available through a link in the detailed help file, or in a Tools menu item. But to use it from the palette today, the user has to drop it on a block daigram, open the subVI and run it. And then remember to delete it again from the block diagram, preferably with CTRL+Z to avoid contaminating the undo-stack. If we could mark that palette item as 'Run VI' then clicking it would just start the ExpressionTester utility.

Perhaps palette items configured to being opened/run/content-dropped instead of the default action should have some sort of indication on it, that clicking it executes a non-default behavior?

Cheers,

Steen

[SteenSchmidt]

If we assume trust in all our installed executables, then there wouldn't be any problem with adding a 'Run VI' option to palette items, as when you install a VIP you can trust what we have put into that VIP.

In that respect anything that ends up in the palettes will have expected behaviour. Then there only remains for us (in collaboration with NI for added glyphs) to signal what behaviour can be expected for each palette item.

[SteenSchmidt]

Note that I'm never talking about enabling the 'Run when opened' execution option in any VI. I'm talking about a setting on the palette item.

[AristosQueue (NI)]

Even with a note/glyph that says "this will run when you click on it in the palettes", I still don't think that putting examples in the palettes is at all a good approach, but if the community really thinks that's the way to go, I'm not going to stand in the way.

[elset191]

Anecdotally, MGI's Menu Building>Examples pallette has been very useful for me.  It would definitely be more convenient if I didn't have to drop the examples to open them.

Definitely NO to auto run from palette.  Or anywhere.

[Darin.K]

Tools belong in the tools menu IMO.  Of course many developers including several based in Austin, TX like to put several in the top level instead of properly nesting them.  (Like 3 NXT items top level, really?)

For you droppers and double clickers, FYI:

http://forums.ni.com/t5/LabVIEW/Micro-Nuggets-Post-em-if-you-got-em/m-p/1713936/highlight/true#M6047...

[GregSands]

Also, if a palette is pinned, then a right-click gives the option of opening a VI. 

[SteenSchmidt]

This is one of those situations where a discussion here is making me change my mind somewhat, thank you all for that. That's actually one of the more downplayed benefits I see with the Idea Exchange, namely the discussions themselves even for ideas that never gets implemented.

My current thoughts on this;

- The ExpressionTester utility is going into the Tools menu and leaving the palette.

- Great tip about being able to open a VI directly from the palettes (Darin and Greg), I didn't know that, or more likely I had forgot. Thanks!

- Regarding examples I accept that my gripe is mainly with the way we create examples today. As in every situation I should concentrate on fixing the primary problem instead of suggesting a brand new feature. Brand new features start in rev 1 with no guarantee to be better than what it replaces, whereas incrementally improving what we already have has a better chance of actual net improvement.

- I still feel that we could improve how we can make IDE plugins, help, and examples. QD is a good start, but is a fix rather than the solution and still not a first class citizen (for starters editors are missing and documentation is scattered). We discuss the topic of IDE user enhancements in many a forum, so I'm content at leaving it at that. Ideas about improving access to help and examples, I can post such here in the Idea Exchange - one small beginning could be the image I posted earlier of a palette, mind you as an additional place to find the features, not instead of the existing places (but let's not discuss it much further here, as it will drown under the wrong headline):

And Stephen, I never feel your opinions stand in the way in these matters. I always value your voice, even in the few cases where we disagree by miles (not the case here). I'm always prepared to change. So in short, thanks for the talk 🙂

Cheers,

Steen

[AristosQueue (NI)]

> I never feel your opinions stand in the way in these matters. I always value

> your voice, even in the few cases where we disagree by miles (not the case here).

Thanks.

> I'm always prepared to change. 

Me too, generally. There are topics where I'm going to insist on some extrordinary evidence before shifting, but I'm open to listening. The "open and run" which is where this thread started is one of the few "I can't even imagine a scenario where you could overcome the downsides". 😉

But you start talking about making examples more available, or improving the tutorial experience of LabVIEW? I'm right there with you.

[FabiolaDelaCueva]

I like the idea of having some way of linking to examples fromt he palette as described by Steen.

It really just boils to UX (User Expereince) and DX  (Developper experience). When I install a toolkit for the first time, I will explore its palette and see what it has, I would love to have it right there a way to launch the examples that are linked to this particular toolkit. For internal toolkits I have done it by having a subpalette called "Examples".  This was a bandaid. 

I have also tried building examples into my toolkits and like Steen, I refuse to do it, because of how hard the current process is. 

We need an easier way to guide the user towards the Example Finder when they are more likely to be looking for it: The first time they explore the palette. After that first time, I would probably use Quick Drop to get to the functions and might even go to look for the examples in the example finder.

Great discussion!

Thanks Steen and AristosQ for the insight.

[TimVargo]

A full year later, and I have come here to give one more Kudo to this idea; specifically the idea of placing two more buttons on the pallet menu, Examples and Help, such as in the mockup by Steen.  I do have two supplemental ideas to add: 

1. The new "Examples" button could invoke the Example Finder, but either link directly to the specific example(s) that belong to the current pallet, or at least pre-populate the Search field with keywords that would direct the user to those specific examples, and even maybe press the "Search" button for them.  This would not only be a useful method for integrating easy access to examples for the package developers, but would also keep re-introducing the users to the Example Finder, each time they explored a new package.
1. This alone does not solve the issue of how hard it is to create examples suitable for the Example Finder, but that could be solved separately; either by NI, or by JKI building an automated way to accomplish this into VIPM.
2. In the meantime, the pallet editor could provide a new option (called Examples Target?) which would tell the new button on the pallet to either pass arguments to the Example Finder, or to optionally open up the folder where the examples live, or even to specify a VI which would be a front-end to multiple examples (uh oh, the evil "Run when opened" again).
2. The Pallet menus already have a Search button (see Steen's mockup), which presents a window with two tabs: Functions & Controls.  What about adding a third tab called "Examples" which would limit search results only to examples?  This too could be used to raise the visibility of Example Finder, by opening the Example Finder when an example item is selected from this search; linking directly to the selected example.  In this case, the Example Finder would probably be used under the hood, as the engine that is doing the actual searching as the user types.