Halloween Demo Day

 It’s a tradition: Every year on Halloween (or as close to it as the work week will allow), tons of LabVIEW developers set up shop at their desks and demonstrate features or products they’ve been working on to all comers. The email goes out to the entire company (in Austin, anyway) and for two hours, (most) work stops as people come by to check out what we’ve been working on.

Today’s that day! I just spent the past half hour blowing up balloons and attaching them w/ribbons to bowls of candy that will go at each demo station. I’ll post pictures or videos if I get them, later.

Preview of LabVIEW 1.0, 1986

In the comments on my last post, Yair pointed me towards this preview of the LabVIEW 1.0 beta, all the way back in 1986. Enjoy!

Interesting Articles

• Here’s a review of the original Macintosh, done in 1984. It’s amazing to read this now with 25 years of perspective and realize both how different it was and how similarly things still work today. But even back then some people seemed to “get it”.
  
  When LabVIEW was first released in 1986, it was for the Mac, because that was the dominant graphical platform of the day, and LabVIEW is and has always been a graphical language. Makes sense to me. (We actually have a couple LabVIEW R&D members who’ve been around since version 1.0 – if you came to NIWeek in 2006, you saw them present onstage.) It wasn’t until 1992 that the first Windows version appeared.
• Learn information better by getting it wrong first. This is an interesting idea, and it makes sense to me. Answers are always better when they come from within. Here in LV R&D we encourage tech writers to find answers to their problems (given the proper resources) before asking others for help. This often involves getting it wrong. But even outwardly, I employed this concept when I designed the Statechart Module Getting Started tutorial. How? I instructed users to build a broken statechart – and then try and run it. The idea is that the resulting error would serve as a sort of opposite-approach to good statechart design – e.g., here’s what not to do. It also gets users familiar with the error-reporting mechanism in the software and one of the key rules of statechart development.
  
  I guess the challenge is that if you fail too much it becomes frustrating and demotivating, so there’s a fine line to walk. We certainly don’t make a habit of publishing documentation that leads to failure :-)
  
  
  

Interesting Articles

I find myself reading a lot of tech news sites. I sometimes email these links out to developers or other technical writers if they are interesting or have applications to LabVIEW/NI, but I figured, why not share them with the world?

Here's are a few things I came across lately:

• Don't offer preferences to users if you don't have to. I think about this sometimes as we design software here ... oftentimes I'll hear developers arguing over how a feature should work and I'll think "just make it a user preference." But recently I'm starting to feel like users can get overwhelmed by ginormous, scrolling Options dialog boxes. (Not to name any names, haha.) Similar to BBEdit mentioned in the article, the version of Lotus Notes we use at NI has a type-ahead filter in its preferences dialog ... so you can search for preferences among its ginormous list.
  
  I'd bet that a Jeff Foxworthy might say ... if you have to improve usability by letting users search through your list of preferences, you're probably giving users too many preferences. And I imagine that once you give users preferences, you can't remove those preferences in future versions. Because that ruins their editing experience that they've customized. Much better to not give the option in the first place and make an intelligently-informed decision about the behavior.
  
• Users don't read -- or, they read the absolute minimum. This is a running joke in our department. And by "joke" I mean "concern". Does anyone actually read our documentation? I think many technical writers have this concern. And I think the answer is "not unless necessary." Personally, that doesn't stop me from putting my best efforts into shipping quality documentation. But it does mean we have to keep things in perspective. Although we support and provide polish for the software, we are not the software. That should be priority #1.
  
• The science of irrational behavior. I find this article fascinating -- might have to pick up the book. I can this playing out when we determine ship dates -- but really, just about anything (a co-worker mentioned this behavior coming into play when determining how much to sell a TV for). The first person to make a guess sets the tone for the rest of the discussion. The Slashdot commentary on this article led me to learn about Planning poker, which is a) hilarious and b) really, really interesting. (If we do this at NI, I certainly don't see it.)
• Ubuntu's first bug. This makes some of our issues look rather trivial ...
  

I'm a little surprised I don't read any technical writing blogs :-) Maybe I should start ...

Leica & LabVIEW

Leica makes some of the highest-quality, precision-engineered cameras in the world. WIRED magazine recently caught up with them and took a tour of their facility in Solms, Germany. In one of the shots, you can see a LabVIEW application (designed by Ramitek GmbH) being used to test the M9, Leica's newest camera. It's kind of awesome to see LabVIEW being used to help control tolerances as fine as 0.0001 mm. That is tiny!!

DPreview.com did a similar tour back in August, and some LAVA forum members noticed additional screenshots of our software in use.