Request for user feedback: Just-In-Time Advice

[Ben]

Hi Stephen,

Thanks for asking!

Thanks for the effort!

I would like to recomend the efforts of this nature be re-directed.

I do not think the experienced user (whom I would suspect is  the target audience audience of any subject that involves tossing a propety and adding a method) is best reached through an in your face pop-up.

The first time I saw it was when I dropped a seq structure. My reaction was that this was built-in advertising since this was one of the features being introduced. I stopped what I was doing and proceded to find the option that shut it off. I can not comment if any of the other pop-ups would have been useful.

The redirection I would like be concidered is enhancement of the documentation that already exist rather than pop-ups.

Aside:

Q: How many computer programers does it take to edit a manual?

A: Zero. That's an editor problem?

Returning:

The LV 7.1 upgrade notes is a total of 21 pages (in english).

I would like to see more along the lines of your comments posted previously re:the property to method change be included in the upgrade notes. What I have in mind is changing the nature of the release notes from the minamalistic approach currently used into something that would actually make for interesting reading. It is a chore to read them now.

At the same time, the manual should be updated to reflect the changes.

Discalimer: If this is documented somewhere, please direct me!

1) Waveform Charts!

There is a lot of power built into the waveform chart but very little was ever said about its capabilities. The following sentence is the only waveform specific comment in the section devoted to Wavfeform Charts.

"

If you pass charts the waveform data type, the

x index conforms to the time

format specified.

"

The ability to plot non-periodic updates to a chart is a great feature that would otherwise require an XY graph and abckground buffers and the potential for demanding GUI updates. A reader has to be pretty imaginative to read that from the write-up on Wavefrom charts.

2)Customizing GUI objects

A number of us have discovered ways of getting at the properties of GUI objects and modifying at run time. These methods seem to work well so I suspect they are not just an accident. Specificly I am thinking about;

a) You can replace an index control with a slder if the slider is an I32. Once replaced it makes for a great modification but, What were we supposed to have read to have learned that?

b) Creating a reference to a graph>>>cursor palette will let us change the position of the cursor label at run time. Again, what were supposed to read to learn that?

So...

What I suggest is that as enhancements are being developed and exposed, stop and throw together some words that can be passed to the doc. group to let them know what they should say about the new changes. By putting the stuff in the manual and the release notes, the information will be where we expect it to be when we decide to go looking.

The following is just the insight of just one engineer:

I am a limited being. I have limitations.

Limit 1

There is a limit to how much information I can accept process and mantain. I have to make an active effort to shutdown and filter the barage of information that bombards me daily. Pop-ups, like junk mail are a distraction that I attempt to elliminate.

Lmit 2

I can only keep a limited set of information current at any given time. Paraphrasing Sir Aurthur Conan Doyle "The humane brain is like an attic. Sonned or latter you have to start throwing things away". I make a living by knowing the right information at the right time. To do this, I try to monitor what information stored where. My attic consist of a lot of treasure maps. I do not need a treasure map popping out of the stack evertime I pass by its shelf.

Done rambling

Ben

[Peter_B]

Even though my thoughts will echo others' already here, I am writing this so they can be counted (assuming the R&D guys haven't already made up their mind !)

I do read the user manual to find out about all the new features in each version of LabVIEW.  However, since I don't re-read the manual as a matter of course, then it's possible that I may forget about using a particular feature when it may prove useful.

To help prompt my memory, I support the idea of JIT dialogs popping up at least once, as long as each one gives me the option of not displaying that particular one again AND an option of never displaying any JIT dialog again.

I would also like to see more advanced level new-feature suggestions pop up in dialog boxes.

regards

Peter

[W Baity]

I also found it annoying and disabled it long ago - so long ago, that when moving to a new computer, it takes a while to remember how to turn it off.

[LuI]

Hi Steven and all the other LabVIEW Magicians,

I started using LV with v3.0 or 3.1 on WfW3.11. LV has gone a long way since than. Thanx a lot.

I disable the JIT whenever I have to (temporarily) install the FDS on a machine that is supposed to run just an exe. Why? Because I am annoyed by that popup.
In such cases LV has no chance to detect if I am a newbie or already know this. And it seems I always get the very same 'news'!

I'd like some of the suggestions as given by others.
1. A kind of hints that can actively be shown by a user that likes some more hints AND whenever he likes.
2. A better documentation of new features as mentioned by Ben.
I often have to set up some test code just to get the idea the devellopers had of the intended usage of a node. A simple example directly available from within the help window would be very wellcome, especially for new or changed nodes.
Often eneough some info in the help system is weak as it allows multiple interpretations.  It  is for sure hard to improve this, as both the develloper AND the technical author are some kind of biased  in the sense that they both know the intended usage. I have written a lot of amnuals for SW products in order to know these problems...
The only chance is to provide some examples and ideas on the intended usage and probably provide it to some beta testers as well.
Another good idea was a kind of task list for new features that can be executed by all those interested in the new feature.

just my  0.02
Greetings from Germany!<br>-- <br>Uwe

[joergh]

Just my 2c - I also find it annoying and disable it almost at once. As someone else pointed out, access to the list of hints at any time would be useful.

[Rexbo]

I also find pop up menus annoying and would prefer they have a default of off and you have to take action to turn them on versus the current implementation.

Rex

[sth]

There has certainly been an outpouring of interest in this. I think there are a couple of items

1. JIT must be easily disabled for a single session without changing preferences
   
2. Pop up windows are distracting and many people find them VERY annoying
   
3. There is utility in the JIT, but it should be up to the user to decide what "time" is right
   

I use the error warnings sometimes to validate my code for potential problems (just as "lint" is used by C programmers). The JIT advice could be used the same way or even from the same diaglog box. It would be very useful to look at the JIT after you have done a quick prototype structure of your program. Then as you decide if this is the way to go, ask if there are suggestions from the JIT system.

BUT one of the problems with the warnings is that it lists all the problems with the VIs in vi.lib. There can be LOTS of warnings in that code that swamp those from your own code. The same could be true with JIT. I don't really want advice on how to improve code in vi.lib. Though NI should do this before releasing it. Of course they should reduce the number of warnings as well, but I keep trying for an ideal world.

So I still recommend activating this like the error list box (or even using that box) from the menu bar with a non-obtrusive indicator that the JIT system has something to say. This is like politely raising your hand and waiting your turn to speak instead of shouting out at inappropriate times.

[Jim West]

I also disabled the JIT... along with abridged menus, automatic tool selection, automatic wiring, X's on broken wires and basically every other new LV GUI feature.  As a user since 2.2, I am fairly ingrained with the 'old' ways.  I found the automatic tool selection to be the most annoying.

Jim West

[User002]

Salut.

I don't like them or the idea behind them. When i need something, only I knows what, and i look for it. I would also like seeing those things in the release notes. I would like to see the format of the release notes changed, because i'm bored long before the end of the document and rarely reads it in its entirety. I would suggest someking of video, intercative or not, that i could watch in the morning when i sit in front of my pc and calmly wait for my body to boot up in the day mode.

Goodday.

[Kevin_Price]

---

Aristos Queue wrote:
Let me highlight one particular JIT... in LV7.0, we added two new VI Server methods for VI Refnums: Open FP and Close FP. Prior to 7.0, you would tell a VI to close its panel or open its panel by using the property FP.Open, and pass True or False to the property....

...So we added a JIT that appears when you set a property node to FP.Open telling you about the new methods.

---

I work under a few different installations / versions and don't even recall offhand where I've turned off the JIT option and where I simply ignore them.  I would generally characterize them as a minor annoyance, however I would also have to say that the specific VI Server example you posted worked exactly as designed.

I know I have a tidbit in my head that the Invoke Node methods "Open FP" and "Close FP" are to be preferred over setting a Property Node value to True or False.  I've gotten in that habit now over the last few months but until reading your post, I wouldn't have been able to identify where the notion came from.  I've gotta believe that one of those JIT's popped up when I first tried the old property node method, I noticed it, read it, absorbed it, used it, made a habit of it, and forgot where it came from.  So this one, in fact, did work unobtrusively for me.

Overall, I'd support some of the earlier suggestions that make it possible to selectively disable JIT's.  As a fairly experienced LV'er, I'd probably soon turn them all off.   In my ideal world, there'd also be a menu option to sweep through my code hierarchy and list those same suggestions -- on my request.  Such a menu option would bring up a dialog where I could choose which categories of JIT's I'd like to check and which to skip.

-Kevin P.