Portfolio > Writing and Editing > Software Help Documentation > API Reference

Project Overview

At National Instruments (NI), I write for the Applications and Embedded Software team. One of our main products is the company's flagship software, LabVIEW. LabVIEW uses a unique, graphical programming language, called G Dataflow (G), that was created by NI. The G language contains thousands of unique functions, called nodes, that perform diverse sets of operations. A large part of documenting LabVIEW is creating reference content for these nodes to help users easily find the right programming elements to accomplish their goals. The goal of this project was to document a set of LabVIEW nodes that allows users to create and
manipulate matrices.

   Skills

• Technical Writing/Editing

• API Documentation

• DITA

• Interviewing Content Experts

• Following a House Style Guide

   Tools

• XML

• XMetal

• DITA Content Management System

• Rally

The Process

Same Difference

Around the time I started at NI, the company launched a new version of LabVIEW called LabVIEW NXG. This new version of the software created a wealth of documentation work. Writers also faced some exciting documentation challenges as we worked to support users through using a software that was familiar but also new and different. The goal of product documentation at NI is to embody the company’s mission of empowering engineers to do more, innovate faster, and easily integrate new technologies. To document the matrix nodes, I did extensive research on matrices and the process for documenting nodes in LabVIEW NXG. In the original version of LabVIEW, matrices, and the functions included in the software to manipulate them, behaved differently than in the new version. My challenge in the research phase was to consider how to document enough for users to be successful and understand the differences while not confusing new users who were unfamiliar with the previous version of LabVIEW.

Manipulating Matrices

Once I had a basic understanding of the user’s needs, I met with all the stakeholders for this set of nodes, gathered information, and drafted my content. I also reviewed the existing documentation for similar nodes in the previous version of LabVIEW to see which portions of the content I could edit and reuse in my new help content. As I crafted my content, I paid careful attention to the differences between the old version of software and the new version and considered how these differences might impact users. I then implemented the established process for documenting nodes, so that the user could view the help content for the nodes both in software as context help and in the LabVIEW online manual.

The Product

Once stakeholders on both the documentation team and the development team reviewed and approved the content, I was ready to publish. The node documentation process allows the writer to use the same content to create two different outputs, one for in-product context help and one for the web. This allows users to access the most critical content within the software environment and, if they need more detailed information, click a more help link that takes them to the full help online.