Just-In-Ti​me Advice: Details on the design decisions that lead to today's behavior

Question

This is the update about Just-In-Time Advice design that I promised last week in an
earlier post.
The feedback received from this forum will be helpful in modifying the
Just-In-Time Advice dialogs (JIT dialogs) in future LV versions. JIT
first appeared in LV7.0, and I waited until now to really poll for
feedback so that I could hear how it actually affected users... I
guessed that if I polled when LV7.0 first came out I'd get the "MS
Clippy must die!" response. :-) Given the feedback, I suspect there
will be changes to JIT's behavior in the future, though don't expect it
in the next release. We generally keep two or three versions of LV in
the pipeline, and feature sets for the next immediate release would
have been determined long ago.
JIT dialogs grew out of a consistent problem we face when we change the
behavior of any aspect of LabVIEW from one version to the next: how do
we let the experienced users know about the change? There were two
comments that appeared repeatedly in the feedback:
include information in the Upgrade Notes
I can only take in so much information at one time
These two conflict with each other. I am fairly certain that everything
for which a JIT dialog exists is mentioned in the Upgrade Notes, along
with a host of other changes. Someone pointed out that the Notes were
21 pages long in a recent release. Our tech writers do an amazing job
cleaning up the sometimes cryptic notes from developers: "I changed XYZ
to PDQ. You might want to mention that in the UN." Asking them to make
the Notes a thrilling read that will be memorable from first page to
last is a bit much. (Though, tech writers, if you're reading this, I'm
not adverse to seeing an attempt!)
So, like several other programs in the world, LV decided to look to a
system whereby information can be supplied when it is needed. There's a
lot of bad perception around features like this, so we walked
cautiously.
Here are the basic feature requirements:
We are targeting
upgrade customers, not new users. Everything in LV is new to a new
user, and they are the group most likely to actually read documentation
about a feature. Upgrade customers generally assume nothing has changed
until they get burned. We want to call their attention to the change
before that point.
We want something that takes up very little screen real estate
We
want something that is easy to get out of the way while the person is
working -- Clippy had all these annoying "I'm going away now"
animations.
We wanted to be able to be able to update the user whereever in the LV editor they happened to be working.
It must be easy to turn off.
Continued in reply...Message Edited by Aristos Queue on 08-26-2005 07:39 PM

Answer 1

A large part of JIT was trying to draw the compromise between insisting, "Hey, you've never seen this, pay attention" and staying out of the way. The comparison to "backseat driver" made in one post was very accurate. I've posted all this information to try and give insight into what we were up against when designing JIT. I figure it will help if we get feedback that understands the problem we were trying to solve. And, if nothing else, it lets you know that the programmers in R&D who make your software really aren't secret MS Clippy fans.
To close, I'm going to give a brief description of each of the JIT dialogs found in LV7.0. In each case, we felt that the change in LabVIEW was important enough that a customer proceeding down the old track would appreciate knowing about the new one. Generally, our reasons were in one of two categories: either the user was about to create a bug for themselves by using the old or because we felt the new way was a significant improvement of productivity/usability.
First Launch -- Immediate direction to the What's New help page and information about the Tools>>Options settings.
AutoTool -- We disabled the TAB key and made AutoTool, first introduced in LV6.1, the default behavior. If you wish to argue about the wisdom of this change, that's for a different thread. But the fact that the change was made seemed like something we should tell users.
Timestamp data type -- When you told a Numeric to format for date/time, as you would have done in LV6.1, we wanted to point out that LV actually had a new datatype, with its own control/indicator, that could save you a lot of headaches and improve precision.
Custom Probes -- When users first create a probe, we wanted to let them know that they had more debugging power in the new version by using custom probes.
Flat Sequence -- When you drop a stacked sequence structure, we popup to tell about the flat sequence structure. This was an oft requested feature, and it does make diagrams easier to read.
Custom Error Codes -- One of the uses of the General Error Handler is to define your own error codes. So when you drop it, we popup to mention that the error handling of LV has significantly improved to let you define errors that are portable with your application and across your company, instead of tied into a particular VI.
Clean Up Wire -- A new feature of LV7.0. Not everyone likes the "route my wires while I'm working" feature, but selective use of "clean up wire" can be very powerful in helping to quickly turn a mess of a diagram into readable code. We pop this up when the user moves wire segments around by hand.
Automatic Error Handling -- This popup tells you what just happened the first time that an error dialog appears while you're running your VI, even though you didn't drop an error handling subVI into your diagram. This feature did well enough in beta testing that we decided it should be enabled by default. The JIT popup helps clarify what this is.
Poly VI Selector -- What is that ring control that just appeared under my Poly VI on the diagram? The JIT tells you.
Front Panel Open -- I mentioned this one in the earlier thread. The old "FP.Open" property was unacceptable for a lot of use cases. It lead to ambiguous situations and buggy code. The new Open FP method and Close FP method and the FP.State property (which is an enum, not a boolean) are more up to the task of correctly controlling your VI front panels.
DAQmx Code Gen Help -- Gives some information about the code that the new DAQmx generates for you.
Thank you, everyone, for the feedback. We keep LV improving version over version. The JIT was an idea to solve a problem. With the feedback, we have enough information to evaluate that solution and either refine it or try something else.
Footnotes:
1) The state panel is that set of buttons where you find the run arrow and execution hilite button.
2) Some of you will be happy to know that the "New & Changed in version X" page of Tools>>Options is an idea we've decided to continue in the future. It's been very popuplar. Also, it doesn't appear to be common knowledge that you can carry your config file with you when you upgrade. On Windows and Linux, just copy your the config file from your 6.1 install into your LV7.0 directory. Or 7.1. Or 8.0... :-)