We are deep in the middle of planning for 2010 right now. One of the areas we want to continue to invest in (or perhaps raise our investment) is around user groups. Working with user groups can be a tricky topic for us – the best groups are those run completely by customers, and they tend to be the ones who don’t want a lot of interference from NI trying to “sell” them on products. On the flip side, we are often asked for new technical content that can be used for user group presentations.
Feel free to comment on this topic – I’ll create a poll to make it easier to respond:
Physical User Groups If you are looking for more information on user groups. you can learn about physical user group meetings in your area at http://www.ni.com/usergroups
Virtual User Groups We have a new capability on our Web site for creating virtual user groups. Most of these are organized around specific topics like “Building Large Apps with LabVIEW” or “RF Testing” and so on. You can see a list of these at http://decibel.ni.com/content/groups
Feel free to comment with any specific ideas for future user group meeting topics you would like to see…
For years, NI’s LabVIEW leadership (Marketing and R&D – yes, that would be me and my compadres) have taken a fairly hands-off approach when it comes to commenting in the LabVIEW community – in particular, forums on external sites like LAVA or INFO-LV. I am not talking about the typical technical questions, but more about the posts that are controversial – like when people start questioning our intentions or believe that we have made an outright wrong decision on some policy or other. In the past, our approach has been to sit back and rely on our very active and supportive user base to jump to our defense rather than ourselves because it might come across as NI “tampering” or being “heavy handed.” In reality, that is an “old school” approach that we need to change. I believe that today, we need to be more open to jumping in and sharing our perspective on these discussions where we can (sometimes we can’t comment on revenue or strategy issues that are not public yet). Many users often wonder aloud in these discussions if we (NI management) are listening. We are – many people monitor INFO-LV and Lava forums here at NI. When flames spark, we sometimes fail to act. I don’t expect to change anyone’s mind, but just the fact that we are listening and sharing our perspective is a good start. I hope to use this blog to share these perspectives – whether in reaction to a particularly spirited discussion we see on the forums or in discussions with customers, or as a premptive strike on topics where we are looking for feedback.
I shouldn’t be too critical. About four years ago, we made some pretty significant changes to our End User License Agreement to accommodate home use and use on multiple computers that was spurred on by an INFO-LV discussion. So we try to do what’s right most of the time – we just don’t always close the loop with those of you who are chirping on the forums.
The truth is, for most of our customers, it’s not about the big policy decisions or strategy and positioning that is interesting – its mainly about the technology and how you can get the most out of it. This is another, more relevant example of where we are planning to get more involved. We have recently developed our own “blog college” training session to get some of our R&D engineers prepped and ready to enter the blogosphere. You will see new blogs in 2009 authored by some of our engineers in areas like developing large applications in LabVIEW, Embedded Control with LabVIEW, Advanced math, signal processing, and simulation with LabVIEW, and general LabVIEW development techniques. We want to show you techniques to maximize your investment in LabVIEW and expose you to some of the newer areas you can use LabVIEW, directly from the desks of our experts.
For those of you who think the whole “LabVIEW is great for multicore programming” story is a bunch of hype, you need to check this out…
But first, a short digression. One of the coolest (and more frustrating) things about working on LabVIEW is the fact that it can be used to solve so many different applications. Big or small, test, design, or control – LabVIEW again and again comes up in the most incredible places. When you find yourself talking with an NI person about LabVIEW, you quickly get the feeling that LabVIEW is “all things for all people” – which of course breaks every rule of marketing and product positioning. But the reality is, you can use LabVIEW for a lot more applications than you think. Our long legacy of test, measurement, and data acquisition sometimes gets in the way of people realizing that LabVIEW is a potential solution for other app areas.
One such area is advanced, high-speed control. LabVIEW is uniquely positioned to combine advanced algorithms with best-in-the-world I/O capabilities. Combine these algorithms with the parallel/multicore capabilities of the LabVIEW programming language – and you’ve got some real power.
But rather than read about it, take a look at this YouTube video from Darren Schmidt - one of our math and analysis algorithm experts. Darren has been toying around with running LabVIEW algorithms on an Nvidia Cuda GPU (stay tuned for some libraries coming soon on NI Labs), and in the process has gotten himself and team plugged into a large telescope application. This video was shot at the Super Computing Conference, where LabVIEW was a finalist for the Supercomputing Analytics Challenge.
I just got back from the RoboDevelopment Conference in Santa Clara. It is clear that the “cool factor” of Robots is definitely a winning strategy in getting our kids involved in science and engineering again – based on the number of conversations I had with teachers, administrators, and students this week. The energy around FRC, Lego, and all the other educational programs around robotics is incredible. (If you want to get involved, see my previous post). It’s also amazing to see the number of real business opportunities in industry and the military around robotics and autonomy as well that are helping to drive the need for these future engineers.
I have to give a shout out to Jeanne DIetsch, the CEO of Mobile Robots Inc, who gave one of the keynote presentations for the conference. In a real display of guts and faith in her company’s technology, she shared the keynote presentation with 3-4 robots that helped her present. It went off pretty well, and her company’s basic robotics platform looks quite impressive.
The other thing that was obvious is that we need to ‘go virtual” again if we are to make a bigger splash in robotics. I am not talking about Virtual Instruments, but this time, its all about simulation. It seems that robots are complicated and expensive to build. Combine that with the fact that you may not know exactly what they are going to do when you send them on their way – you really need a way to write your robotics code so that it will run in a simulator first, before the hardware is actually ready. This would be yet another example where the software is truly the instrument. We’ve done some pretty cool integration with Solidworks to co-simulate – definitely more of that kind of work is needed.
Technical support has been a key part of our success at NI. Sure, some of our customers who are gurus and have used our products for many years, have expressed concern about the experience level of some of our front line support engineers. But the point is, support is important to us – ever since customers started ripping open a PC for the first time or tried to install a Windows driver, we realized we need to be on this support thing.
However, the word “support” is one of the more overloaded terms out there. We (NI) and our customers use that term to mean many different things. Recently, we realized that we don’t really have a documented support policy somewhere that outlines all of these types of “support” and what you should expect. We are working on that now, and I wanted to get some opinions from the outside world. So far, I have compiled the following aspects of our business practices that would fall under the term “support”. Weigh in if I have missed something:
For a given version of LabVIEW (a version is the development environment and all associated modules and toolkits for that particular version release):
Providing maintenance releases
Providing patches for specific customer issues on an as-needed basis
Testing and validating new hardware that comes out after LabVIEW
Having technical support engineers who answer questions over the phone or through email
Developing and maintaining technical content specific to this version on ni.com
This list outlines what we do. What is not clear is FOR HOW LONG? So the real question we are attempting to answer is to set some guidelines for timeframes for each of these items. For example, how far into the future should we test new hardware drivers with LabVIEW 8.6? Is it reasonable for you, as a LabVIEW user, to expect that any new hardware that comes out next year should work with LabVIEW 8.6? Of course. What about 3 years from now? How about 4? Same thing for maintenance releases – is it reasonable for us to ship a LV 8.6.2 three years from now? Probably not. However, we might create a patch for a specific customer who has hit a critical problem with no workaround.
Am I missing anything from this list?
Do you have any comments on timeframes for each of these?
I will be posting our proposal soon, but I thought I would throw this out there now to see if anyone has something else to add. (Of course, there are related issues to this – like what is the process for upgrading to new versions, and how long will we support specific operating systems – but that’s a different post)
We first released LabVIEW in 1986 as a graphical programming language on the Macintosh. By now, you would think that we have a good idea of what it is. However, as many of you know who are LabVIEW users – the product is constantly evolving (we like to think “improving”) over the years. In fact, one of the most common misconceptions I hear from customers is when they tell me “I know all about LabVIEW… I used it in my lab in college 5 years ago.” Inside, I am thinking – dude, you have no idea how much LabVIEW has changed in 5 years.
The fact is that LabVIEW has evolved tremendously, particularly over the past few years. We have great plans for LabVIEW – which go way beyond a simple programming language. The challenge is how do we serve our good customers of today, while at the same time continue to evolve and improve the platform while they are using it? I am reminded of an actual conversation I had with a few customers this year during lunch on Thursday of NIWeek. I am reminded of it because, by Thursday – after a week of sales conference sessions, keynote presentations, and editor meetings, I usually try to keep my lunch open so I can sit at a random table to get some feedback from users – to be honest, its a way to get my feet back on the ground and in touch with reality again. This year illustrated exactly our challenge. I asked the group at the table “How do you use LabVIEW and what do you like about it?” The first customer, from a big mil-aero account, said they are working on a large application with LabVIEW and, coming from a C programming background, they really liked the direction we were going in with the project, OO programming structures, and libraries to better serve the programmers of the world. The second customer said “I use LabVIEW like a calculator to do quick and dirty things. So keep it simple – I don’t need a lot of the new features you are building.”
So in an attempt to rest my brain and chat up some LabVIEW users, I was once again confronted with one of the ongoing challenges of the universe – how do we present a powerful programming language and a high-level engineering tool in one package? The interesting thing was that both of these customers were basically happy – but they were using the product in completely different ways.
This debate was stirred up recently in a great info-lv posting, started by David Moore (from Moore Good Ideas) who started the thread with a post entitled “Will LabVIEW survive?” – which was more about balancing quality and testing with innovation. It is amazing how these user forums spark up some of the most passionate and thought-provoking debates among our users – usually involving people coming in on both sides of the issue. While most of the posts and discussions are about “How do I do X in LV?” or “Does anybody have a driver for X?”, we sometimes see these great philosophical debates too. In the ensuing discussion, Mark Smith from Sandia had a great response where he compared LV to an application for doing relatively simple things (like Excel) as well as an IDE for building applications, and that perhaps we should consider packaging LabVIEW differently based on all of the different features now baked into it. We ARE constantly looking at new and different ways to package and explain LabVIEW for the world – but we have to be very careful because we have such a rich history behind us and we don’t want to mess things up. So its a challenge – but perhaps a blog will help. (If not, at least it will help me move forward on my master self-aggrandizement strategy!)
I am hoping to tap into some of these topics to keep the passion flowing from our users, and provide more of a dialog. I am already breaking rule #1, which is don’t prattle on too long about something. We’ll see how it goes.
Posted by pasquarette 
Posted by pasquarette 
Posted by pasquarette 
