Survey for LabVIEW users

[Coq_Rouge]

May I donate my 10 bucks, to some Labview charity group. Like the group that help people with event addiction. I will also like to give some to the group using electroshock then trying to cure Express VI dependence.

[Ray.R]

May I donate my $10 towards a bill that bans all forms of surveys..?

[Ben]

---

jcarmody wrote:

---

cscaffid wrote:

Help us make LabVIEW better!  

---

How in the world will this survey help make LabVIEW better?  You're guilty of doing something underhanded.  I don't know what it is, but I've never seen anybody more guilty of it than you. 😄

---

Mega-dittos!

THis shows you what I think about this misleading post.

 

Ben

[cscaffid]

Wow, I never expected such a negative bunch of responses.

In response to the complaint that this is "underhanded", I want to explain that this is a serious attempt to understand how people make decisions about <i>not only</i> mathematical analysis tools (such as LabVIEW), but also other tools (such as animation tools) as a baseline.  This was NOT meant as something underhanded, and I apologize if it came across that way. We really do want to understand how people are using these tools and, particularly, where they fall short in terms of supporting code reuse.

Ok, how will this survey help us make LabVIEW better?

Code in LabVIEW is highly diagrammatic and visual. In this sense, it is similar to spreadsheets, animations and several other kinds of languages; it strongly differs from traditional textual languages such as Java and C++. Research shows that the visual layout can be very helpful when people are creating certain kinds of programs (for example, see Pane reference below). But to date, there has been almost no research on:

(a) whether people reuse visual code as intensively as they reuse textual code

(b) whether people are as likely to reuse other people's visual code, vs other people's textual code

(c) whether people who score high on Bloom's hierarchy of competency reuse code more  than those who are less competent

(d) whether people who use visual languages  go to the same places for help as those people who use textual languages 

(e) whether people who reuse visual code have a higher whitebox/blackbox reuse ratio than people who reuse textual code

We have hypotheses for every one of these questions (based on the Pane work, below, as well as other research by other colleagues). Answers to this survey will enable us to test our hypotheses. I'm not going to come out and say the hypotheses, however, because that would bias the survey.

The bottom line is that we want to see whether people use and reuse visual code differently than textual code. And to the extent that people coming to the survey from different websites (including LabVIEW forums) give different answers to these questions, we will know that they are struggling with certain aspects of the corresponding tools. Hopefully we will get plenty of serious answers to the survey, and then we will do follow-up interviews with a selected group of people who have taken the time to give meaningful answers to the survey. During these interviews, we will have a chance to ask about their ideas for improving LabVIEW and the other tools of interest to our respondents.

So, again, please accept my apologies if this survey came across as insincere. The government's bureaucracy at our university (called the IRB) micromanages much of what we have to put in the text related to this survey, so I didn't have a lot of flexibility. (I am not even allowed to edit the survey questions now!) I hope that this longer post will cause you to take another look at my advertisement of the survey, and that you will choose to participate -- or, at least, you realize that we're doing the best that we can here, given the constraints on our research.

Here's the research by John Pane that I mentioned above. He's a good researcher who has done some solid work and invented some clever programming tools.

J Pane and B Myers, Usability issues in the design of novice programming systems, Technical Report Human-Computer Interaction Institute Technical Report CMU-HCII-96-101, 1996.   http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.3701&rep=rep1&type=pdf

[Ben]

In the interest of helping LabVIEW...

I completed that survey and am sure it can in no way help LV since it only asked about spreadsheets that I do just to avoid using a calculator. I can alos say that I would have probably answer all of those question in a completely contradictory manner if they were asking about LV, but they didn't.

This was cut-n-pasted from that doc

---

 

Examples: Visual programming languages have a high viscosity. [Green 1996] measured

an order of magnitude increase in time to make a small change in the

LabView visual programming language than in a textual language. In order

for the programmer to preserve readability, LabView required many

"enabling" steps before the goal could be addressed.

---

What version of LV was available in 1996 ?

Was un-do available in 1996?

like I said, I filled out the survey but if you are serious about helping LV, the old reseach should be tossed as obsolete.

Ben

PS: If that was a peer-reviewed paper, how come LV is spelled LabView? someonf familiar with LV knows the differnce.

Message Edited by Ben on 04-23-2010 12:00 PM

[tbob]

Examples: Visual programming languages have a high viscosity. [Green 1996] measured

an order of magnitude increase in time to make a small change in the

LabView visual programming language than in a textual language. In order

for the programmer to preserve readability, LabView required many

"enabling" steps before the goal could be addressed.

WOW!  That statement could not be further from the truth.  Undo didn't come along until LV 4 or 5, sometime in the 90's.  So it may not have been available in 1996.

[rolfk]

---

tbob wrote:

Examples: Visual programming languages have a high viscosity. [Green 1996] measured

an order of magnitude increase in time to make a small change in the

LabView visual programming language than in a textual language. In order

for the programmer to preserve readability, LabView required many

"enabling" steps before the goal could be addressed.

WOW!  That statement could not be further from the truth.  Undo didn't come along until LV 4 or 5, sometime in the 90's.  So it may not have been available in 1996.

---

Undo was just about around the corner then. Still that is not a killer issue. The issue is with what someone is familiar. If someone asks me to do a small change in a Visual Basic or Delphi program I'm likely to quote a multiple of time to do that change than a similar change in a fairly structured LabVIEW program (explicitedly excluding diagrams that span over several screens and are sprawled with globals and other nastinesses).

Also changing a C program while it could be easy may involve a lot more testing and investigation for side effects than it would likely in LabVIEW for me, eventhough I believe to understand C fairly well.

[Ben]

---

rolfk wrote:

...

Undo was just about around the corner then. Still that is not a killer issue. The issue is with what someone is familiar. If someone asks me to do a small change in a Visual Basic or Delphi program I'm likely to quote a multiple of time to do that change than a similar change in a fairly structured LabVIEW program (explicitedly excluding diagrams that span over several screens and are sprawled with globals and other nastinesses).

Also changing a C program while it could be easy may involve a lot more testing and investigation for side effects than it would likely in LabVIEW for me, eventhough I believe to understand C fairly well.

---

To Rolf and all of you that have been doing this longer than me...

Could you please confirm or rule-out a bit of a pattern that I have noticed?

Does it seem like the LV community have improved the structure and readability of their diagrams over the years?

The introduction of control refs so we can push the details of the GUI fiddling down into sub-VI has helped quite a bit since we don't have to do that in the top level VI anymore.

It just seems that back when I started using LV seriously (1999) the diagrams were horendous. Since the advent of the NI forum and Christian beating on the "style drum" things are much better.

Any insight?

Ben

[herrlin]

---

muks wrote:

Jim,

One sure thing. Reading so much of texts will make you like labVIEW even better...

---

I was going to ask for some more pictures because I a cant under stand this survey.

[rolfk]

Ben,

It's hard to make a definite statement here. There are many more nice diagrams out there today than 10 years ago. But there are also many more LabVIEW programmers and many of them still fresh and doing the things that we all have done in our beginnings.

If I look at my code from 15 years ago I feel there has been certainly improvement in style. Sometimes it borders towards being anally retentive, some is because of new insights and things I learned, some is due to new features in LabVIEW that simply didn't exist 15 years ago in LabVIEW. And no I do not necessarily mean control references, which I try to minimize if possible. Personally I do for instance not find it a good idea to cluster all control references into one big cluster to pass around. I try instead to keep the control reference manipulations to where they are needed (the VI whose FP they ar located on) with some utility VIs sometimes to do certain operations on a limited set of controls.

In terms of code structure I still feel the single best invention in all that time was the event structure. It solved the problem of dealing with front panel events very nicely. That the configuration dialog of it took so long to get the long needed facelift is unfortunate but doesn't make the event structure less important.