UI, Documentation, and Polish

I'm not sure how it is at other places, but part of being a technical writer at NI is dealing with usability. We are often the first non-engineers/non-developers to see a feature in action. We come across many malformed and confusing dialog boxes, interface widgets, organizational structures, and so on. In LabVIEW we have a great usability advocate in Christina Rogers, who recently made a post about usability and UI. She's also documented many of the UI issues and standards that developers should take into consideration when implementing a feature. Having been present at numerous discussions of "What should this dialog box look like?" I certainly appreciate her work and guidance! She also serves as the arbiter on many UI issues, like, "Should this dialog box button say Close, Finish, or Exit?" It sounds like a trivial question, but as Christina can tell you, issues like these can profoundly affect the user experience and perception of our product.

I bring all this up because of a recent post on Ars Technica about Microsoft's last-minute polish of the Vista UI. Look at the two shots of the dialog box side by side. The Change button is now Rename. The Network ID button is now Join. The text accompanying each button has also been simplified. These are the kinds of changes that we, as technical writers at NI, deal with and have influence over.

(On a side note, you'll notice that I bold the name of buttons you click on -- this is a side effect of writing with NI's company style guide in mind for so long!)

The post about Vista relates to NI in so many ways. Like Windows, LabVIEW is NI's flagship product, the one with the most visibility. Obviously LV is not as big (in market dollars or in lines of code) as Vista, but still. The article's point about last-minute bugs being expensive to fix is a valid one. We have to deal with all those bullet points too, except for the Accessibility one. This is why technical writers are so important in catching/addressing usability issues as early as possible -- the earlier we file a request to change a UI, the less money it costs to fix the issue. At crunch time you have so many people doing so many different things that issues like these often get neglected or deferred in favor of more "Showstopper" issues. Not to mention the overall added stress on the developers during crunch time.

My point is this: an ounce of prevention is worth a pound of cure, right? This is what I tell myself when I file a bug report to a developer over a trivial little issue, like a radio button that should be a checkbox, or a text box that is too short, or a dialog box title bar that doesn't make any sense. This is also what I tell myself when I recompile a .CHM file to rearrange the words in a single sentence, fix one misspelled word, or resize a single image. All these little issues add up to a more professional product that I'm proud of being involved with.

Along the same lines ...

Last month I attended the Austin Game Conference, in which Blizzard VP of Game Design Rob Pardo spoke about Blizzard's legendary "polish," or the overall impression that you're using a well-developed professional product. He said that polish is not something you can just add at the last minute, or even at the last month. It has to be built into the software plan from the beginning. He also said that polish is not just one single thing, like the speed of World of Warcraft's mouse cursor or the shading on the menu bars. Polish is a combination of thousands of little decisions that all get implemented during the development cycle.

This part of his speech stuck with me, because it reminded me of what we tell developers when we hassle them about UI and documentation issues. Sure, in the grand scheme of LabVIEW, nobody cares if a button is labeled Close, Finish, or Exit. They all do the same thing, right? But if we can guide the user on the path they want to take, or anticipate their move and help them make it through intuitive UI design, that adds to the polish. Same with the documentation. No one's going to not buy LabVIEW if we misspell a word in the help. Along the same lines, we've shipped versions of LV that don't include any help for a given feature. I highly doubt that this situation affected sales.

But high-quality UI and documentation adds to the overall presentation of the product and helps users complete their tasks. All the hundreds of little things add up to make LabVIEW a more professional, usable, and complete product.