Birth of a Feature: The improbable story of VI Snippet

The next version of LabVIEW will be coming to a presentation near you very soon.  I thought I would share the back story about one of the new features that you will see called the VI Snippet. 

First, the problem statement.  For many years, we’ve been working on better ways to empower users to share their code with other users – through better Web features on ni.com and better ways of packaging and distributing your VIs.  The popularity of the platform, and the expertise of our user base, can be measured in some ways by the number of VIs available on the Web – it’s a kind of currency for LabVIEW. 

We have a few challenges in enabling users to share code:

1. LabVIEW is graphical, so you really need to see the block diagram to understand what techniques you want to learn more about
2. Seeing the diagram ins’t enough – it needs to be easy to get the VI from a Web site into your LV environment so you can experiment with the code.  One advantage text-based languages has is you can simply cut and paste text from any document into your environment to transfer it.  LabVIEW code needs to move that easily. 

With these seemingly insurmountable hurdles in the way, enter the Hogg – that would be Simon Hogg, one of our talented young LabVIEW product managers.   Simon had some ideas on how we can create a better experience for users to share code, but rather than try to convince R&D to build something, he went off and built it prototyped it himself (the beauty of LabVIEW for fast prototyping).   The idea is simple, but when implemented comes across as magical.  In LabVIEW 2009, you create a special screen shot of your VI – called a VI Snippet – which embeds the actual binary information of the VI into the image.  You can then post that image anywhere on a Web page and other users simply drag the image onto a blank block diagram in LabVIEW and voilá! – the actual LabVIEW code is there, ready to explore, edit, or run.   Check out the video below to see it in action:

Once Simon created his prototype, it was quickly dubbed internally as “the Hogg Feature” or “the Hogg” for short.  We’ve even taken it to its verb form – similar to “googling” or “xeroxing” something, when you distribute a VI Snippet, you are “hogging it.” 

Naturally, there was the small step of actually designing, implementing, and testing the feature in R&D to make it work in the product for real – but having a working prototype was a great influencer.  If one of our product managers can prototype the feature, then certainly our R&D guys can develop it. 

So I wanted to share this story to show that even the best-laid plans at NI to smoothly manage the feature set of upcoming LabVIEW versions can be disrupted here when someone combines initiative with the power of LabVIEW programming to make something happen (and because the Hogg is a cool feature).  I look forward to “hogging” some VIs posted by the c0mmunity of LabVIEW users in the near future.

What do you want to see in a roadmap?

I’ve been busily updating our LabVIEW roadmaps for NIWeek next week and once again I am faced with the challenge of creating a presentation that is relevant to a crowd of LabVIEW users – we are doing so many things with LabVIEW, that is more difficult than you think.  So as I am preparing for next week, I thought I would hit the user base to see what you guys want to know. 

My goals for a roadmap presentation are:

1. Show your loyal users that you are hearing them and understand their concerns, and share our plans to address these concerns

2. Explain our higher-level strategy and investment directions (for example, if you aren’t considering the benefits of using LV FPGA with our RIO architecture, you need to)

3. Recap where we are today – most users can’t keep up with everything we are doing

4. Speak to the skeptics in the room with an honest assessment of key issues that have and share plans to address those issues (to push them to reconsider)

5. Capture reactions to our plans, questions, and open issues from the customers at hand.

Maybe I am missing something.  Respond with any other general topics that you would like to see in a LabVIEW roadmap discussion, or send in specific questions or comments so I can comment and/or include them in my presentation.

Building Amazing User Interfaces with LabVIEW

Back in the good old days (a phrase some of our younger product managers are tired of hearing me say), our sales guys had it easy.  Simply open a blank VI, drop down a knob or toggle switch, make it move, and wait for the oohs and aahs (and orders).  The user interface – how you develop it and how it interacts with your programs – is and will continue to be a key differentiator for LabVIEW.  In recent years, as iPhone apps and other hot new devices have become the talk of the tech world, people have begun to expect that UIs should look sexy, with glossy controls and color schemes. We’ve heard the low, rumbling feedback about  how LabVIEW UI elements could use an update, and believe me, we’re working it. In the interim a few employees and LabVIEW users have formed the UI Interest Group   to share best practices and templates for building modern, eye-catching controls for LabVIEW.  There is actually a lot you can do to create your own custom controls that look very modern, unique, or conform to some specific design themes.  Check out some of their work: 

Creating your own custom controls is fairly simple. Each control is made up of several elements that you can replace with your own images. For example, a LabVIEW gauge is made up of the following objects:

To create your custom control you just replace each object with your custom design:

Now it does take a good eye for design and a decent image editing tool to make these, and I don’t have either. If you’re in my boat, join the UI Interest Group to download the controls they’ve built and learn more about making your own.