LabVIEW 2010 New Years’ Resolutions

After listing out what I thought we needed to focus on for 2009 in the form of “New Year’s Resolutions” last year, I am now getting pushed by some of the folks here in our Marketing group to come up with my 2010 resolutions list.   The good news is that a fair number of people (including some internal people here at NI) read my list of resolutions and tracked our results through the year.  The bad news is that now it has become an expectation – so here in the first week of February I am laying out my 2010 list – better late than never.

Before looking at a new list, it’s important to understand that everything on the 2009 list is still in play.  I don’t think any of them are completely “finished”, but for the sake of progress, I am going to put most of them into “business as usual” mode for 2010.  However, two items from last year jump out such that they require continued focus in 2010:

1. Provide better support for third-party tools - We made a lot of progress in 2009, but most of it was in the area of internal awareness and investment.  You should start to see more results externally in 2010.  Its important that we follow through on the investment we made last year. 
2. Get serious about upgrade and deployment pain - This is an area where I think we can do better.  The hardest part of this is quantifying our improvement – how do we know that upgrading from an earlier version to LV 2009 is better?  We rely on word of mouth and personal experience through our Tech Support and system engineering resources.  I feel like this is still an area of unfinished business, so its staying on the list.

Now for a few new items for 2010:

1. Simplify the product learning curve
2. Help users manage their NI software better
3. Build better tools for capturing customer input

All three of these are topics which will probably not be able to be solved in a year.  However, similar to supporting third-party tools in 2009, we have to make some internal plans and investments this year if we are to make progress in the future.   I hope to use forums like this blog or NIWeek to preview our ideas with the user community to ensure we are on the right path.   I’ll add some more detail to these in subsequent posts… In the meantime, I can at least say that my LabVIEW 2010 New Years’ Resolutions list is official:

1. Simplify the product learning curve
2. Help users manage their NI software better
3. Build better tools for capturing customer input
4. Support third-party tools (carryover from 2009)
5. Reduce upgrade and deployment pain (carryover from 2009)

2009 Review #6: User Input

My 2009 Resolution #6 was Develop new, more effecitve ways to capture user input.

As you can imagine, with the number of experienced LabVIEW users out there, and the fact that we have some many direct channels for feedback (direct sales force, NIWeek, seminars, tech support, etc), we sometimes struggle with the sheer amount of feedback we get.  Ideas for features, enhancements, and minor annoyances all get catalogued and reviewed for each release, but priorities often cause some of them to stay on the list for years.  At that point, we have trouble putting them all into context and comparing relative importance. 

We realized last early last year that for these “small but important features” the users were the best group to prioritize them for us.  I talked to a customer (who was clenching his fists at the time)  in Germany last Fall who was incredibly frustrated with his inability to know what is coming and/or make suggestions in a way that had a chance of being heard.   He told me that over the years, sometimes the most minor tweaks to features could have huge impact to the developers using the products every day – even though they may appear small and unimportant to NI, they can make a huge difference if you are using the product a lot. 

The Idea Exchange went live for exactly this kind of user input.  When we introduced the LabVIEW Idea Exchange in May 2009 we weren’t sure what kind of feedback we’d receive.  Would our users submit any ideas?  Would we get enough user feedback on those ideas to know which ones were most important?  Would we get bombarded with ideas that would be difficult to implement?

I’m pleased to say that since its launch, we’ve received 749 ideas, 2,889 comments on those ideas and over 14,000 votes from LabVIEW users.  Most ideas deal with improving the LabVIEW UI and programming experience, and we’ve dedicated R&D engineers to building several of the top ideas into LabVIEW 2010, and we plan on implementing even more as time goes on.  I thought I’d let you in on my top five user ideas that will be in LabVIEW 2010:

#1

Including LabVIEW Version in a VI Snippet
Submitted by:  Michael Aivaliotis

I’ve blogged about VI Snippet in the past, but as a quick reminder LabVIEW’s VI Snippet feature allows you to create an image of your block diagram with the code itself embedded in the image.  You can drag and drop VI Snippet enabled image from any webpage or email directly to your block diagram and the full LabVIEW code appears. 

We’re continuing to develop this feature as VI Snippets become more and more popular.  Over time it will be important to document the LabVIEW version on each image so that you can know which images will work in which versions of LabVIEW.  VI Snippets created in LabVIEW 2010 and beyond will include that versioning information.

#2

Move/Shift terminals in the icon connector pane
Submitted by:  tst

This is the best idea you never thought of.  If you want to swap two connector terminals on a VI icon today you have click on the icon terminal, then on the front panel object, for every control or indicator you need to change.  Beginning in LabVIEW 2010 all you need to do is click on the icon terminal and drag it to the new placement.  The existing icon will switch to where the moved icon came from.

#3a

New Boolean Constant Design
Submitted by:  altenbach

So I’m cheating a little and including three ideas as part of one larger idea:  conserving space on the block diagram.

The old LabVIEW Boolean constant displayed both a T and F symbol with the current value highlighted with a dark green box. That design is fine if you’re only using a few of these constants, but what if you’re using a dozen or more in an array?  All you really need to see is the current value.  The new layout is much clearer and frees up valuable block diagram real estate.

#3b

Local Variables Redesign
Submitted by:  altenbach

Another idea in the “saving block diagram real estate” category, this idea removes the extra border around a variable and instead communicates input/output with an arrow on the left or right side of the variable name.

 #3c

View Cluster Constant as Icon
Submitted by:  chris.b

The final of the three space saver ideas focuses on reducing the footprint made by a cluster constant on the block diagram.  The following image (submitted by chris.b) is a little over the top, but you get the idea.

#4

Indicate the display format of string constants
Submitted by:  altenbach

A string is a string…unless it’s a hexidecimal string, or a password string, or…you get the idea.  Just like we’ve done previously with numeric constants, string constants in LabVIEW 2010 will include a glyph that indicates the strings format. 

#5

Increase default “Maximum Undo Step by VI” to 99
Submitted by:  PJM_LabVIEW

If you code like I do, you never use undo…This is a relic from the old days of LabVIEW, when computer memory couldn’t handle more than a handful of undo steps (if it’s any indication of how long I’ve been around, I can remember when LabVIEW didn’t have an undo function…scary, I know).  Prior to LabVIEW 2010 a user would have to go into the Options menu and change the undo step default from 8 to whatever value they wanted.  LabVIEW 2010 will save you that step when you install and configure it

#6

Adding labels to wires
Submitted by:  falkpl

You can assign labels to all kinds of objects in LabVIEW, but what about wires?  Sure you can place a free label on or near a wire, and Block Diagram Cleanup generally leaves it alone, but couldn’t we make it easier?  falkpl’s idea is great for when you have a large block diagram with long wires.  That way you can keep track of which wires correspond to which variable without having to scroll all over you diagram to find its source or destination, plus it will minimize all the fingerprints on your monitor…

2009 Review #5: Upgrading and Deployment

My 2009 Resolution #5 was Get Serious About Upgrading and Deployment Pain.

This is probably the most complex and difficult challenge we face as a platform provider – How do we continue to develop and evolve the technology going forward and still bring along the tremendous history of user applications with each new version?  The testing matrix for LabVIEW is huge – covering features, operating systems, hardware, modules, toolkits, etc… By going to annual realeases, we raised the bar on upgrading.  It’s clear that annual releases won’t work as a strategy if it is too difficult for our users to move to the new versions.  We’ve put together a lot of best practice material at NIWeek and on ni.com to share our thoughts on how to attack the process of upgrading your application.  We’ve also published a few case studies of real-world applications that we helped upgrade with the customer that cover not only the process we followed, but also the technical challenges and improvements we uncovered when moving to a new version.   The bigger issue is of perceptions – LabVIEW users are wary of new versions, which is understandable when you consider the performance requirements and mission-critical nature of many of their applicaitons.   However, we know we have to break down these perceptions and get to the heart of the real issues.

In 2009, we also commiossioned a group of application engineers to interview users, review technical support requests, and study other companies on deployment.  Deployment, like upgrading, is a huge issue that has many facets, including (but not limited to):

• Application builder for creating executables
• Deploying a system using TestStand and LabVIEW
• Deploying a RT and FPGA systems to hardware
• Replicating any of these systems in high volume

We continue to catalog issues, ideas, and features needed to address these types of deployment issues. 

LabVIEW R&D has deployment on their radar as well.  You will see some fundamental improvements as soon as LabVIEW 2010 in these areas.  We’re even making changes to the VI file format and defining new packaging options that should bring big improvements to those of you building large systems with LabVIEW (but that requires its own blog post). 

In short, I believe we’ve done a good job defining the playing field of issues and provided some documentation on best practices and resources for users.  Real technical improvements should start to show up this year – but we have a long road ahead.

2009 Review #4: Support Policies

My 2009 Resolution #4 was Clearly Document Our Support and Lifecycle Policies.  We managed to deliver on this on our Web site - now the questions are:

1. Have you seen this yet?
2. Does it make any sense?

Our goal was to answer the question “How long will NI support my version of LabVIEW?”  This, it turns out, is actually a pretty complicated question to answer, because everyone has their own definition of the word “support”.  For NI, we’ve defined the following dimensions to our support policy:

• How long will we answer technical support questions about your version of LabVIEW?
• How long will we release service packs or patchs for your version of LabVIEW?
• How long will we make new hardware work with your version of LabVIEW?
• How long can you continue to purchase your version of LabVIEW?

I’ll let you follow the link above to see the answers to these questions.  We didn’t really have to “create” these policies as much as simply document how we’ve been operating for many years.  As customers ask about special support considerations or long-term agreements, it had become clear that every customer had their own understanding of what we do as a “standard policy” for support, and in fact what we mean by support.  These documents now state our policies publicly.

We also realized at some point during the year that our operating system “support” was also not very well documented or understood by our customers.  Occasionally over the years we’ve had to make decisions to stop supporting (there’s that word again – in this case, it means stop testing new versions with a particularly OS) specific versions of operating systems.  Our approach in the old days was to explain our decisions to our sales people so they can “alert our key customers about this change”.  That approach obviously doesn’t scale to today.   Instead, we’ve created an Operating System Roadmap for LabVIEW.  Our goal is to update this document every six months, and to give at least a two year notice before we de-support a particular operating system so you can plan accordingly. 

Oh by the way, in case you haven’t heard – LabVIEW 2009 does run on Windows 7 (and yes, Windows 7 is better than Vista… and XP).

2009 Review #3: Roadmaps

My 2009 Resolution #3 was Be More Transparent with our Roadmaps.

This is an area that I can think we need to continue focusing on.  I am often asked by customers or sales people to “present the LabVIEW roadmap” as if there a single document that explains our plans for LabVIEW.   Because the capabilities of LabVIEW have continued to expand through new toolkits as well as embedded targeting capabilities, it transcends the specific areas that a particular customer may be using it.  For example, many of our customers using LabVIEW for automated testing often are not aware of or don’t know what to make of our embedded capabilities.   With LabVIEW FPGA, we are continuing to push the definition of a virtual instrument, enabling users to define their own hardware literally at the gate level.  Our CompactRIO hardware is oftentimes presented as a distributed industrial control option, which may seem irrelevant to our test customers.  With PXI-based RIO hardware, including the new FlexRIO platform, users can build some incredible customized measurement solutions.

With all that said, we’ve presented our Test, Embedded Control, and Industrial roadmaps – that include embedded topics as well as our new embedded software testing software VeriStand – at NIWeek as well as at five different AT-CAB (Automated Test Customer Advisory Boards) and IE-CAB (Industrial Embedded Customer Advisory Board) meetings around the world.  We also present these to customers by request – so feel free to email me directly if you are interested.

NIWeek also plays a key role in laying out our plans for LabVIEW – and NIWeek 2009 was no exception.  Two technologies we highlighted in the Day 2 keynote were Web LabVIEW and the System Designer.  If you weren’t able to attend NIWeek, take a look at these videos to learn more. 

Looking ahead to 2010, I’d like to get more aggressive at presenting the LabVIEW roadmaps to a larger number of our customers.  I don’t have anything specific in mind, but I keep thinking about an iPhone Software Roadmap briefing that Apple put together about 6 months before they delivered these features.  They posted it on the front page of Apple.com.  I don’t pretend that LabVIEW has the same reach as an iPhone, but this approach seemed pretty effective – I remember watching that video, and 6 months later I ended up buying an iPhone!

2009 Review #2: Support Third-Party Tools

My 2009 Resolution #2 was Provide Better Support for Third-Parties.

We’ve had a lot of activity around the concept of a Product Partner program this year, and you should see the fruits of our efforts start to surface in 2010.  There has always been a fairly active ecosystem of consultants, integrators, and tools developers around LabVIEW.   The NI Alliance program was established in the early 1990’s and continues to be the umbrella under which we support these partners.  However, the Alliance program has always been an extension to our sales efforts, and has naturally leaned toward integrators and VARs as a focus.   For partners developing add-on tools, they need better technical integration tools from R&D and broader visibility through Marketing.   Earlier this year, we intiated a new effort to build a better foundation for product partners in the LabVIEW platform.  We’re calling this effort “LV2Partner” or “LabVIEW to the Partner”  (a play off our FPGA focus that we often refer to as “LV2Pin” or “LabVIEW to the Pin” for direct hardware design with LabVIEW). 

Some of the things we’ve done this year as part of LV2Partner include:

• Introduced LabVIEW Scripting on NI-Labs and created an API Group on ni.com/community to help promote and support the uses of scripting. (This decision can be traced to a specific meeting with Jim Kring of JKI Software)
• Built an internal team in R&D dedicated to supporting the effort for creating addons to LabVIEW.  This team is still in its formative stages, but will be developing tools, guidelines, and certification programs for these tools.
• Developed tools for enabling third-parties to add activation to their products (to allow for evaluation versions with a consistent approach for all addons).   These tools will be introduced in LV 2010.
• In February 2010, we will roll out our LabVIEW Addon DevCenter that will package all of our guidelines and recommendations for building addons into a single Web site.
• For LabVIEW 2010 beta, we will roll out the certification program, in which our engineers will be recuiting active partners to move their products onto LabVIEW 2010 with the opportunity of being certified by NI.
• Piloting a project to resell third-party tools, to see how we can bring the reach of NI sales and marketing to our partners.

We made some major strides in 2009 to invest in internal resources and programs that focus on third-party tools providers.  Although our intentions are good, and the investment is there – the proof will be in the delivery of these ideas in 2010.  I’m excited about the path we are on and think it is a critical program for NI, our partners, and our customers going forward.

Jeff Meisel, our Product Partner Manager, is “the man” here internally, so feel free to comment or email him directly with your questions or feedback at jeff.meisel@ni.com.

2009 Review #1: Get NI more active in the LabVIEW Community

Now that 2009 is winding down, it’s a good time to review where we’ve been and look ahead to 2010.  Specifically, I will review some of the goals I outlined in my 2009 New Year’s Resolutions post and share what we’ve been able to accomplish and what we have in store for 2010 in these areas…

My 2009 Resolution #1 was Get NI More Active in the LabVIEW Community.  Over the years, we’ve had a policy of silence on the user discussion boards, and this year I was hoping to be more proactive when issues arise.  It’s been a relatively quiet year in terms of major flame-ups on the forums – perhaps due to the terrible economic conditions we’ve all had to battle through.  There was an interesting discussion about our annual release policy that came up in January on info-lv.  I opened the floor to David Fuller, one of our LabVIEW R&D Directors to respond to the discussion as well.  We also shared some of our cross-product integration testing processes in May after I had been involved in a few customer discussions about our testing matrix. 

Secondly, we introduced a new feature on our Web site called Groups for organizing user discussions and feedback around specific interest areas.  The top 3 most-popular groups are organized and run by product managers:

• #3 is for those of you interested in better user interface features and components in LabVIEW
• #2 is for users building large applications with teams of developers with LabVIEW
• And the top group focuses on LabVIEW APIs and scripting.

And finally, we’ve made a concerted effort to get some of our talented engineers to share their insights more with the user community through regular blog posts.  We’ve had over 200 new blog entries from 10 different engineers this year – some of them established and others new in 2009.  You can check them out at ni.com/blogs.

After reviewing our progress, we’ve actually done better than I expected.  As always, we can do more, but 2009 marked a significant step up in our involvement with users through some of these new tools.  Feel free to add any thoughts on where we can do more.

Waterloo Labs strikes again!

Chances are good that you’ve already seen this.  If not, be sure to check out the latest episode of Waterloo Labs: How to drive a car with an iPhone.

Enjoy.

Hardware Abstraction Layers and the German Rail System

See if you can guess what this photo is?  (Answer below).

How do you architect your test software to manage hardware obsolescense?

Is hardware obsolescence a challenge for you?  I particpated in two different Automated Test Customer Advisory Board (AT-CAB) meetings in the past month in Germany and France where we discussed strategies for handling test system hardware obsolescence.  The challenge is well-documented in mil/aero systems when the unit under test (a jet fighter, missile system, etc) has a life span of 30 years or more, you’ve got to deal with instruments in your test system going obsolete at some point during that time.   In addition to the business aspects of this problem - like budgeting and planning for system upgrades periodically, and developing a strategy for spares and repairs – we work a lot with people on software architectures that make it easier to swap in new instruments without requiring major rewrites and re-validation of code.

This continues to be a huge focus area for test engineers.  It’s refreshing when customes really open up and share key concerns and issues that they are struggling with.   For the latest AT-CAB, we actually have the customers break up into groups and brainstorm, prioritize, and present back with their recommendations.  It can also be an eye-opening experience – for as much as we talk about developer productivity, one customer explained that they spend 25% of their time on developing and 75% validating, updating, and maintaining their test code.  These discussions are great to help drive our efforts at the issues that matter most.

We’ve worked for many years on instrument drivers over the years.  I was personally very involved in the development of the Interchangeable Virtual Instrument (IVI) driver architecture.  We defined and built a lot of technology into IVI, and we’ve learned over the years that you can’t simply buy drivers to give you interchangeability out of the box.  We have seen companies be successful with a software abstraction layers – many based on IVI drivers and others on native LabVIEW implementations.  We’ve recently created some presentations with some recommendations on how to approach hardware interchangeability for the protecting against obsolescense:

• A white papwer with example code  on hardware abstraction
• A short webinar about hardware abstraction

My Latest Experience on the German Rail System (and Highways)

Now for the picture.  After the last AT-CAB meeting, I joined our European branch marketing managers in Germany to spend a day discussing our software business and LabVIEW adoption strategies (a subject for future blog posts).  After the meeting, we all jumped on the train back to the Munich airport.  One stop before the airport, the train stopped and the conductor announced we are going no further – so we all climbed off the train, over a bridge, and down to a bus stop at the side of the road – where 500 people were in line for a bus that was nowhere in site.  Someone then had the great idea to walk to the airport, amid cries of “the terminal is right there…”   Like most major airports, there are big looping highway exits that take you to the terminal doors.  So what appeared to be a few hundred meters away was actually about 2-3 miles.

I was walking with my colleague from Italy, who joked that we expect this kind of problem in Italy, but the Germans are renowned for their efficiency and timeliness.  I promised him I would post on the topic to ensure our German counterpart was made aware of the situation.   We were laughing at ourselves so hard that I had to take a photo with my phone.  You can barely make out the sign for the exit to the airport above the shuffling masses in fear of their lives (and of missing their plane).  It’s a little blurry because I was walking as fast as I could carrying my bags while trying to avoid slipping off the curb to get crushed by a speeding Mercedes. 

Just another event in the glamorous world of business travel – I’m sure many of you have your own stories.

Are you part of a user group?

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…