Not an Engineer

I was re-reading the post about April's interview in the Statesman, and the last sentence stuck out at me:

...the fact that she is not a programmer or engineer serves her well as a tech writer.

This phrase is very true. I said the very same thing to a class of students at UTSA last fall, and I find myself thinking it at the career fairs I've been to recently. Many job applicants hear "technical writer," or sees what NI does, and think "I'm not a programmer" or "I'm not an engineer." To these students, I say, good.

We need more non-engineers and non-programmers looking at our products: testing them, writing about them, and polishing them via documentation or other means. We need creative people with non-technical backgrounds to push back on the developers and say "This isn't designed well" or "If I can't understand it, how will a customer?" After all, just because we're a tech company, that doesn't mean all our customers are technology oriented. Engineers and programmers are trained a certain way, which doesn't always include ease of use or user-friendliness. That's (part of) our job. So in these cases, being a non-techie is very beneficial.

So we don't need, or sometimes even want, you to be tech-savvy when applying for the open technical writer positions we have (hint, hint). When we're interviewing or looking at resumes, what we are looking for is that you are interested in technology or are curious or passionate about it. We don't need you to come in and start writing C++ immediately - that's for the programmers.

We do, however, expect you to come in and start writing English immediately :-)

The VI Road Show

Welcome the newest NI Blog member - the VI Road Show. This is actually a vlog (video blog) that will take you around the country (and possibly world) as the owners showcase NI's employees and customers.

Interview w/April Brinkmeyer

The Austin American-Statesman recently interviewed a co-worker of mine, April Brinkmeyer. She is a technical writer for the LabVIEW core product. Here's a snippet:

Writing, reviewing, updating and improving the program's extensive help documentation in-program, in print and online is an on-going project for Brinkmeyer and the others on the documentation team. She also sits on committees that are tasked with improving help systems across the board and ensuring consistency. Though Brinkmeyer went through an intensive training program and had to learn several new applications, the fact that she is not a programmer or engineer serves her well as a tech writer.

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.

Bloggers vs. High Schoolers in Writing Competition

/. has a bit this morning about bloggers competing with high schoolers on the SAT essay. If you like, you can even rate the bloggers' submissions yourself!

Here's the essay question, timed at 20 minutes:

Directions: Think carefully about the issue presented in the following excerpt and the assignment below.

I have learned that success is to be measured not so much by the position that one has reached in life as by the obstacles which he has overcome while trying to succeed.'

-- Booker T. Washington

Assignment: What is your opinion on the idea that struggle is a more important measure of success than accomplishment? Plan and write an essay in which you develop your point of view on this issue. Support your position with reasoning and examples taken from your reading, studies, experience, or observations.