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

[AristosQueue (NI)]

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:

1. 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.
2. We want something that takes up very little screen real estate
3. 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.
4. We wanted to be able to be able to update the user whereever in the LV editor they happened to be working.
5. It must be easy to turn off.

Continued in reply...

Message Edited by Aristos Queue on 08-26-2005 07:39 PM

[AristosQueue (NI)]

LabVIEW does not have a single "LabVIEW Application" window onto which we can post messages. Conversations about whether or not it should have one are for another thread. If we tried to put a message into the VI state panel or something like that, we would have to put the same message on every VI, or move it around as you changed focus. Adding to the Context Help didn't seem to be an option -- that can clear out rather fast as you move the mouse, and having it change in response to something other than the current mouse position might be confusing. We looked at tip strips, but those are for temporary flickers, and are hard to interact with. So, we decided that a popup dialog be our approach.

There were a lot of intense discussions when designing that popup. But here's what we decided:

1. The popup needs to be small. We made it take a small piece of the screen in the upper left hand corner to minimize how much it interfered with the operation at hand. The idea was to make it as ignorable as possible.
2. The small dialog did not leave room for any details about the feature. So we had a one-line to catch a user's attention, and then we could expand into a larger form if they decided they were interested. In retrospect, I think we made a mistake here. We used the phrasing "Learn about..." That's new user phrasing. It probably should've been something more like "X has changed. Click for details."
3. The dialog could be dismissed by clicking on the [X] button. Gone. No lingering. That was important to a lot of developers.
4. To prevent annoyance, there's a 5 minute delay. Once you see a JIT pop up, you won't see another one for 5 minutes, even if you do something that would normally trigger a JIT. We wanted to be helpful, but had no wish to dump a barage of information. As some have pointed out, there's only so much information that a person can absorb at a time.
5. If the user does just hit the [X], we do not disable that particular dialog. We felt that, ok, they don't have an interest in learning about this now. We'll bring the same information up again later. At some point (we hope) it will come up when the user is not massively busy and can take a moment to look.
6. To permanently dismiss a JIT takes only 3 clicks. Expand, click the checkbox, close the window. And the record is made in the .ini file not to show that JIT ever again. If you actually launch the online help from within a JIT, the checkbox is clicked for you -- we assume that the user has got the information if he/she went that far.
7. There are VERY FEW popups in LV. In the last thread I said 10 in LV7.0. I miss-counted; there were 11. The point though was to keep it to a small number, and to make them each about a distinctive topic. We didn't want the popup coming up every time you twitched the mouse. Each popup went through lots of review to ask, "Is this really worth telling the user about now?
8. The very first launch of LV includes a JIT telling you about LV's latest version. We had hoped this would get users used to thinking of JIT as an upgrade information box, not a new user tutorial. And it directed you straight to the Tools>>Options page where you could turn off JIT. This was our attempt to avoid the frustration caused by not being able to turn the feature off. I am thrilled that among all the feedback about JIT, not once did I see a post, "I can't turn it off."

Continued in reply...

Message Edited by Aristos Queue on 08-26-2005 07:39 PM

[AristosQueue (NI)]

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... 🙂

[tst]

Well, I, for one, rather like the idea, at least the way it sounds here.

I have to say that JIT is not as bad as clippy, because it was much easier to fully disable (I did it in my initial setup, so I wasn't really bothered by it). As a sidenote, the newer versions of office give you the ability NOT to install the interactive help (YES!!!!!!).

It seems that changing the text to "this has changed" is definitely what would make the biggest difference in helping veteran users not to hate Clippy (sorry, JIT).

Also, just for the record, I like the auto error handling. It's not a replacement for your own, but it's still good to have just in case you forgot (or something).

Also, thanks for asking for specific user input on such a wide scale, thanks for listening, and thanks for LV. Now, just get the fellas from marketing\accounting\whoever to take the price down.

[Waldemar]

Maybe you can even add an option of the level of the data shown.

I mean a few levels of how much different options should be shown:
level1: show all differences
level2: show just a little more important differences
level3: show just important differences
level4: show just the most important ones

Well probably only 3 levels would be more than enough.

My 2cents.

Peace
Waldemar

[sth]

Anything that is a couple of inches does not qualify as small. That size is visually intrusive and demands primary attention. Note this is the size of most web pop-up advertising for a reason. This is not just a coincidence. The size of the JIT window demands the distraction of your attention. Even if it was a smaller window the extra room for the borders and buttons would still make it too large. This is taking way too much screen real estate as it is. If it was your intention to use little real estate you did not achieve the design goals.

Menu bar or better yet window tool bar icons (a small pastel red exclamation mark, not blinking/throbbing or anything else) that would show that the system had some possibly useful advice about this particular VI would be the level that is non obtrusive. When you are in a programming fugue any interruption takes a long time to get back all the possible threads that you are keeping track of simultaneously. Even moving the mouse to the corner to close the window is a serious interruption. If I close it, I don't want it and it comes back in a few minutes anyway. VERY annoying.

If you can't reduce it to a SMALL icon, it will be turned off and then the whole concept of JIT advice becomes so much unused bloat ware. It should only open windows on user demand. I should not have to read the JIT advice for each computer I am working on to make it go away automatically. If I dismiss the advice about flat sequences 10 times, then you can be sure that I really don't want to look at it.

-Scott

[AristosQueue (NI)]

Scott: As I said, LV doesn't have one window. No one really liked the idea of some sort of status message appearing on every single VI panel and diagram. That's what lead us to the window idea.

You said any space is too much space.... what if we did a system utility like the "you've got mail" icon that apears in the system try for many mail readers, and the small corner popup? Sorta like the MS Windows "updates are ready" message? That would be a big effort to do in LV -- I don't think we've ever put together the tools to do it, and I'm certainly not sure what it would take for Mac and Linux -- but would that be an acceptable tactic to attempt?

[sth]

LV has NEVER had just one window. I think you are laboring under the false impression that I have ever used or ever wanted to use a system that had single windows. I am quite happy with completely independent windows. In fact I require it!

BUT if your JIT is smart enough to look at my code and think that it has something to contribute then it should have a different conclusion for each of my windows. Just like the error box (ie broken run arrow) that is different for each window as it should be. SO SHOULD code warnings. They are individual to the VI and as such should be attached to that particular DIAGRAM window. Look at all the menubar space wasted with debug single stepping icons when the VI is not even running. The icons should only reflect possibilities for the current state of the VI. 6 different icons for debugging when the VI isn't running?

I don't have a system tray. I would not really like it attached to my Dock either.

You already have the "show context help" icon up there, it should be something like that but not as dorky looking. LVs icon set has evovled a bit (I did have LV 3.1 up and running on Friday converting and old LV 2.2.1 VI) but it is still very out of date. Newer systems are using shading, throbbing, etc to indicate system status. Jumping Dock items are not my favorite and with dual screens the Dock is a long way away.

Attach the JIT to the Error Dialog pop-up box. There should be a three tabbed box. One for errors, one for warnings and the third would have JIT advice tagged to specific areas of your open (or loaded) VIs. There should be the capability to exclude all VIs in vi.lib so I don't get warnings about the short cuts and stuff done by NI (there are lots). If you attach it to the error dialog box then I can get to it easily with the command-L keyboard short cut. For those who are icon based it should be on the corner of the window possibly as a pull down menu choice from the VI icon on the diagram. That is a very short menu and did not used to allow setting VI properties or editing an icon from the diagram. Change that back so that only diagram type operations (such as JIT/warning list) are accessible from that icon pull down.

Thus I can use it as code review as I can use warnings on suggested inputs etc. My problem is that something as large as a new window appearing in my field of view is an indication that it immediately demands my attention. System shut down, power failures, disk problems crisis like that. Advice about my programming style doesn't rise to that level.

I understand some of the reasons for the original design of JIT. I just think there is a way to improve it rather than have 3/4 of your intended audience hate it and turn it off as fast as possible.