Performance improvement for password protected add-ons by disabling debugging

[Jim_Kring]

My general argument is that LabVIEW, in this case, could have an improved user experience (helping me get the best balance of performance and debugging), while hiding low-level considerations (like the implementation details around the relationship between the password protection and debugging disabled settings).

For example, when I password protect a VI, LabVIEW could say to me, "I'm going to disable debugging, too, to give you better performance, but let me know if you don't want me to do that for you."  And, when I enter the password to unlock a VI, LabVIEW could say, "You'll probably want to debug the code, too, so I'll enable debugging on these VIs (which will decrease performance slightly), but let me know if you don't want me to do that."  In this way, the act of using LabVIEW educates me about how password protecting VIs does not automatically disable debugging, and that disabling debugging will give me a performance improvement -- and, I didn't even have to crack open the manual.

[Daklu]

Christopher Relf wrote:

...I don't know if I could make the call on whether the difference is insignificant - it might be insignificant in one instance, and significant in another.

Well... are you referring to statistical significance or personal significance?  Personal significance, yeah, I agree with you.  It depends on what you're doing.  I don't think there's any question the data show a statistical significance.  A million samples makes for a very small mean error. 

Whether or not the data are valid is an entirely different question. 

Jim Kring wrote:

I agree with Daklu (that engineers tend to not read documentaiton), but would go one step further. Modern software (that's very well designed) should, IMO, not require reading documentation in order to use it

In general I agree with you, at least when it comes to simple tasks.  I think it's reasonable to expect to have to refer to the documentation once you get into complex operations.**  On the other hand, I don't think it's reasonable to apply that expectation to Labview.  Intuition relies heavily on context.  Give a crescent wrench to a mechanic and he'll use it to tighten nuts.  Give it to an amazon tribesman and he'll use it to club a wild boar, then file a usability bug for not killing the boar quickly enough. 

I actually agree that instances where intuition and reality don't mesh could be considered usability bugs.  But the bug isn't necessarily in the api--it could be poor/insufficient documentation, poor/insufficient communication, or several other things.  Instead of changing the api to match your intuition (simultaneously going against others' intuition) I think a better course of action would be to figure out what allowed the incorrect intuition to develop in the first place and take steps to fix that.

(**To their credit NI provides lots of documentation.  So much of it that sometimes it is very difficult to find the information I'm looking for.  That's assuming I even know that I should be looking for information and what information I should be looking for.)

[crelf]

Daklu wrote:

In general I agree with you, at least when it comes to simple tasks.  I think it's reasonable to expect to have to refer to the documentation once you get into complex operations.**  On the other hand, I don't think it's reasonable to apply that expectation to Labview.  Intuition relies heavily on context. 

I agree - and with the finite resources available to NI R&D (like everywhere else), there are plenty of other things I'd prefer to be worked on than something like this. In principle, yes it'd be neat if this (and many other things like it) were implemented. In practise, there's more on the list in front of it.

[Daklu]

Jim_Kring wrote:

For example, when I password protect a VI, LabVIEW could say to me, "I'm going to disable debugging, too, to give you better performance, but let me know if you don't want me to do that for you."  And, when I enter the password to unlock a VI, LabVIEW could say, "You'll probably want to debug the code, too, so I'll enable debugging on these VIs (which will decrease performance slightly), but let me know if you don't want me to do that."  In this way, the act of using LabVIEW educates me about how password protecting VIs does not automatically disable debugging, and that disabling debugging will give me a performance improvement -- and, I didn't even have to crack open the manual.

I don't like it.  Lots of software these days uses dialog boxes to help teach the users with a little checkmark that says, "Don't warn me about this anymore."  (At least it better have a checkbox.  I have little patience for repetitive dialog box ticklers.)  I've turned so many of those off I can't remember which applications have them or what they were warning me about.  I think that technique is largely a cop out when UI designers can't think of a better way to convey important information to users.

[rolfk]

Jim_Kring wrote:

I agree with Daklu (that engineers tend to not read documentaiton), but would go one step further.  Modern software (that's very well designed) should, IMO, not require reading documentation in order to use it (e.g. Have you read the documentation for your iPhone? My guess is that most of its features are not fully documented anywhere (publicly).

-Jim

I don't agree here. I don't have an Iphone, and last time I got one in my hands I couldn't really use it, because I couldn't figure out easily what to do with it, to make a simple call for instance or even just snap a picture. I know it's super easy, and I even have experienced my three year old playing with it after my brother showed it to him on his visit. Three months later it was introduced here and my son was walking by one of those man height dummy displays in front of the Apple store and he was explaining to everyone on the street with loud voice what you can do with it and how. But for me I don't have a need to know, since I don't own it and won't buy one and I don't know how to use it when I get one in my hands. So even "the best usable device on the planet"TM doesn't work easily for someone not needing or wanting to know how it works.

Also what works great in one cultural environment can be a total failure in another. That is something many people forget, since they believe that their way of thinking and reasoning is the only feasable one in the whole universe. And sometimes there is no easy way to design it well that it works everywhere so you end up developing two or three or more ways, or decide to document what you have and might not work ideal for some people.

The same with Apple computers: They are supposed to be easy to use and I'm sure they are, if you start with a clean slate, yet give them to someone who has lived with Windows for some time, and he will get quickly annoyed at llittle things, like how you have to resize windows differently, or that the close button for a window is on the left side and not on the right side of it. It goes further that if you want to change something on the system it can get very hard to do so if it goes beyond visual gimmicks. At last Windows has catched up in that area to Apple with Windows 7 and likely will surpass them with Windows 8 and Ubuntu has made great efforts with Unity to go the same way.

What I want to say is that great usability design is nice and good, but claiming that you can come up with a design that everybody can understand and use without even a small paper explaining the most general concepts used in the design is probably a bit a stretch.

[rolfk]

Daklu wrote:

I actually agree that instances where intuition and reality don't mesh could be considered usability bugs.  But the bug isn't necessarily in the api--it could be poor/insufficient documentation, poor/insufficient communication, or several other things.  Instead of changing the api to match your intuition (simultaneously going against others' intuition) I think a better course of action would be to figure out what allowed the incorrect intuition to develop in the first place and take steps to fix that.

I think you are right here, but you didn't mention that the standards change! What is considered an intuitive design concept by now would have been a total usability failure 20 or even 10 years ago. An Iphone in 2000 would have been at best a techno geek gadget but to expensive and to whatever for most. Give a modern 7 computer or a Mac OSX 10.8 computer to someone in the 80ies and they could not even switch it off! Who the heck is so stupid to not put a power switch on a computer!

I think it is another area where the current patent system is in fact biting in its own tail in respect to design patents. In order for a great design idea to be usable for the people it has to be adapted by many and then gets the new standard by which everything is measured, but once it does it is very lucerative to insist on the patent. Before it is used on a broad scale it is a completely worthless patent. So a design patent holder has to hope that his patent gets copied as only that will make it valuable.