automatically fill context help with predifined options

[GregFreeman]

I am expanding on this idea . As was suggested by others, it would be beneficial to have this in the context help so I have drawn up a small example. See picture...

This idea would give us the ability to add items to the VI description automatically(reentrant, top level/main, modal, etc) rather than typing certain properties out for each time a VI is made. We could do this by simply selecting a checkbox. We should also have the ability to select "defaults" that are automatically added for each VI and this could be available through the tools->options... dialog just like block diagram preferences are. Obviously the option to add our own text would still be there, but this would allow users not to have to worry about if they are leaving out any important properties that should be in the context help with every VI created.

[tst]

How about having a section in the context help window which will show X, where X is configurable for each machine. That way, if you want to see reentrant VIs, you simply check the reentrant flag and any reentrant VI will appear as such in the CH window.

[AristosQueue (NI)]

What if it wasn't an option at all and the CH just showed these things?

I've been getting an education lately in usability from one of our usability experts here at NI. One of the focuses has been on removing options from the environment. Study after study shows that people are more productive with software that has fewer options. The programmers (after appropriate testing in front of users) pick one setting and that's how the software works. It eliminates a huge category of bugs (interactions with different modes don't always get tested, especially if some of those modes are very rarely used). It cuts down on documentation and the amount that has to be taught in a training class. It makes teams of users more effective because everyone's machine works the same way. And it simplifies the environment so that options that are necessary settings are easier to find.

This sort of "let me configure what the CH shows" strikes me as a prime candidate for "don't make it an option, just change the behavior." If it is significant for people to know that a VI is reentrant in order to know how to use it effectively, then we should be showing that. How we show it could vary based on how critical we think it is. Perhaps a small glyph in the corner if we think "people just need to be casually aware of this" vs 72 point blinking red text if it is "critically important and must not be missed." Ok, we probably wouldn't go that far. My point is that having these as options means that they won't be set in most cases, so when there is no symbol or text indicating reentrancy, you won't be able to trust that the CH is at all accurate, so you'll end up having to check VI Properties anyway to really know how the VI is configured. The only way that I see for this to be useful as an option is if the options defaulted to "on" (in which case we might as well not have the options since there are very few times I can imagine where a person consciously thinks, "Yes, I'd like to have less documentation on this VI.") or we have a symbol that proactively shows "yes I am reentrant" and "no I am not reentrant", so that you know whether the option is turned on or not for this VI. That seems... well... silly.

So I'm up for the CH showing more of the config details of a VI. I'm not sure that having options for showing that info is the way to go.

[tst]

In general, I definitely agree with that thinking (although I haven't had the benefit of a usability expert. I had to rely on my own wits and the internets. There's some very useful stuff out there on usability. Also, the systems I create are usually used by a small number of people, so usability is less of an issue). I just don't know if I want that info or not.

I probably wouldn't mind having it, but my suggestion was meant to handle those people who don't want to have it. Having the configuration saved globally would solve most of the issue of "is this setting on?", since you're usually working on your own machine and know it's on or off (assuming you can be bothered to remember), but of course this has its own set of problems. In the end, just putting it in is probably better than having it as an option.

[AristosQueue (NI)]

> just putting it in is probably better than having it as an option.

Assuming it is something to promote at all. That I think is the key question.

And that's probably where I get hung up the most. Reading a diagram, I shouldn't have to care about private details like "is this VI reentrant or not" or "is this VI going to dynamic dispatch or not"? I use an API and it does what it says it will do, and the mechanisms by which it gets that job done are irrelevant to me.

At the same time, the CH is for people who are developing the API in the first place, and having this info in the CH would make it easier to spot the VI that you forgot to make reentrant or accidentally tagged as "run in UI thread".

I think my leanings are to say the CH should be loaded with info and the diagram should be nothing more than the icon to indicate what the node does, not how it does it. But that's a position I could easily be talked out of.

[tst]

You're assuming that there's an "API", which is optimistic. In many cases, there are simply VIs, and knowing that a VI is reentrant can be relevant if it has USRs, etc.

That said, I would agree with you that I usually felt the need for this more when working on a VI then when using it. Enough, in fact, to more than once place a comment on the BD saying that the VI is reentrant. That way, whenever I open one of those VIs, I'm immediately reminded of that aspect of the VI.

[AristosQueue (NI)]

Ooo... now that's an interesting idea... some sort of watermark directly on the diagram telling the configuration of *this* VI. That might be more useful overall, especially if it showed up when you printed or screen-grabbed the diagram.

[tst]

Possibly. I certainly wouldn't want it to get in the way of the code. Maybe something on the toolbar?

I can say that this isn't a convention of mine. It's something which I currently only do on occasion when I feel that the programmer who opens the VI next (usually me) will need to know that the VI is reentrant. The comment is placed in the top left corner and has a different color, so it stands out. If it was automatic, I wouldn't have to do that, but then you might ask "why only the reentrant flag? Why not add other stuff which affects execution (if there is such stuff)?".

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.