Improving examples to get people up and running with LabVIEW

There’s been a recent discussion between a LabVIEW Product Manager and the LabVIEW Champions on example code I’ve been interested in. The Champions had a lot of great points, there are regular meetings and a private discussion forum for communication, and I wanted to expand on a few of the things that come to my mind and see what others think.

Purpose of Examples
I think of two primary goals of an example. The first is get people up and running with a task they’re starting and the second is to teach people about best development practices. Examples as templates should also demonstrate common applications or needs in applications that people can use as a starting point and customize.

The Right Way or the Fast Way
One specific example used by a LabVIEW Champion got me thinking. Let’s say I want to have my application do something after I click on a button. The traditional way to do this in LabVIEW was to use a while loop and detect a value change on a button. This approach is often referred to as “polling” and it can eat up your processors since the while loop is continually executing and reading the value. When the Event Structure was introduced it provided a much better way where we essentially wait for interumpts from the OS so you’re not just spinning processor cycles polling the current value of a control.

Ideally you should use an Event Structure, you application will respond better and the performance of your application and machine should improve over polling. We do though need to keep in mind that some people are just looking to perform a quick and dirty task where using polling is sufficient and faster to write. Many people transition from this to using that code in a larger application and then the polling approach can break down.

In this case I would want any example that uses polling to call out the pro’s and con’s with polling and mention the event structure as the “right” way and ideally provide a link to that example.

Newer Versions of LabVIEW Introduce Better Ways to Do Something
The event structure is a good example of something that wasn’t in LabVIEW at one time. When it was introduced it provided a better way to develop interactive user interfaces. We should really do something with those older examples shouldn’t we? On Developer Zone we do list the version an example is written in but that doesn’t really inform people that there are features in a newer version, one you may be using, that provides a better way to do something.

Improving Examples in LabVIEW
Improving examples shouldn’t just be about creating more example code. I should ideally be about updating existing examples and in some cases deleting or removing them. Examples are installed with LabVIEW and are available on NI Developer Zone as well as other community sites. The LabVIEW R&D feature specification process does have a section titled “Examples Impact”. I’m going to work with Todd, the product manager I mentioned earlier, to revisit what that sections goals should be. In addition to what examples we need to create, things like what examples need to be updated or obsoleted should be considered. There are some challenges to this process as far as how to manage it and track the use of features in examples but those are details, the overall goal should come first and we should find something we can do today and define what we need in the future.

Your Ideas
If you have any other things you’d like to see in examples or LabVIEW to help get you up and running as well as develop your applications please share your ideas by commenting on this post, I’ll be sure to catalog them and share them.

Understanding the “design flow”

We were having a hallway conversation yesterday about how to represent information in a UI. The discussion quickly turned to the “design flow”. To provide a little context we were discussion how designers or engineers making use of signal processing algorithms work. Other terms that come to mind are use cases, information flow, user interaction design. For the design of any product, especially software like LabVIEW being able to successfully put yourselves in the shoes of the end user is worth a lot. It’s never easy since the LabVIEW user base is so varied, many industries, many types of applications, many backgrounds and cultures.

To give a simple example, in one recent conversation we were discussing applications that run on multiple targets. Let’s say a windows machine and a system with a real time controller and an FPGA. Do people work bottom up or top down? Do people start with all the VIs and code and then decide where to target things or do they start with where things need to run  and then put the code down appropriately? The conclusion we reached was  … both. There are lots of shades of gray in between as well. So as we develop any utilities or tools to make the development and management of these systems making sure both approaches are handled intuitively is key.

There was a recent tread on Info-LabVIEW that John mentioned in his post titled “What is LabVIEW? about who it’s intended for and the balance between simpler and more complex applications. When designing parts of LabVIEW and the user experience we rely on a lot of different things to try and get it “right”. These include:

• Having multiple iterations to serve as evaluations points
• Holding internal usability sessions
• Previewing features with the LabVIEW Champions
• Visiting customers in the definition phase with mock-ups as well as during development with prototypes
• Identifying lead users to include through the process for directed feedback
• Sharing ideas still in need of refinement on NI-Labs

Those are the first few things that come to my mind. When you consider the Beta period for a release it’s later on in development so major changes can be harder to make, but the feedback on usability as well as bugs is valuable in short and medium term. That’s why for newer areas we like to get in front of customers to understand how they work day to day when developing applications. This can provide feedback earlier during development when we have more opportunity to make course corrections.

In addition to the issues I mentioned earlier about the things we have to balance like different application types and industries, one issue that is really difficult to grapple is entirely new paradigms. What things are done a certain way today because of the legacy of existing products, technologies and methodologies? What of that legacy is necessary to make it an understandable experience for people and what should be superseded by “new ways of working”? Answering these questions can lead to some passionate discussions, but that’s what makes working on LabVIEW and seeing how it has evolved and continues to evolve so much fun.