Be a reporter, an authority, and a public servant when you write

If you listen, you can hear a very authoritarian tone in some types of technical documents. Manuals and instructions are often that way. “Don’t use this appliance in wet locations.” “Don’t grasp the exposed cutting blades when picking up or holding the appliance.” “Ground fault circuit interrupter protection should be provided on circuit . . ..” And in some cases, like a manual or a material safety data sheet, this strong tone is an appropriate communication style because there are safety and health risks.

There’s another tone I can hear in scientific papers and technical journals written by editors. It is the tone of a reporter. Unlike the authoritarian tone, the reporter’s tone is more of one who is following a line of conversation and describing, or transcribing, the words and concepts heard. In a reporter’s tone, there is an opportunity to capture more than just words. You capture the first-hand accounts, experiences, and insight into how imagination functions.

I’ve published stories that consisted of minimally editing replies to a series of questions I posed to engineers at WETA Digital. It took me a long time to think up the right questions for the Motion Capture Supervisor and Animation Supervisor there. My questions focused on the application of Motion Capture technology in the film Rise of the Planet of the Apes, which (at the time) was about to be released in theatres. These people were using motion capture technology in new ways. Following is an example of text I minimally edited for a story about the film Rise of the Planet of the Apes for Entertainment Engineering magazine:

“An outdoor shoot of this scale was never attempted before so this technology was purpose-built for Rise of the Planet of the Apes. This is the case for many of the research and development projects at WETA; the script tends to tell us where we need to go… Onset work on The Hobbit was performed in a very similar way to how we handled Rise of the Planet of the Apes. The onset setup and the majority of the hardware and basic systems were the same. The difference was in how we processed the data. For The Hobbit we were able to process the data coming through the system in real time and were able to visualize this data directly over the film camera. In this way, Peter Jackson was able to get a fairly accurate view of where the CG character would sit in the shot and he could make framing decisions in the moment. This workflow was helpful with the Gollum sequence, but really paid off when we were motion capturing the trolls sequence. Being able to provide the director with a proper sense of scale for the trolls was a huge advantage. The massive size of the trolls could have proven quite difficult to frame without this ability to properly represent the size in camera. A big obstacle in developing this system was dealing with set lights, sunlight and its reflections on the cars and environment. We experimented with a few approaches but settled on high-powered LED markers that could punch through the competing light sources. The markers were placed on the actor’s body and synchronized with the camera shutter to maximize the marker contrast. The cameras were paired and able to calibrate and reconstruct the markers in 3D. A number of tools were developed to clean up the data and support the grouped calibrations. We also developed a new software that allowed us to more easily adjust for the movement of each pair quickly as we were often having to rush quickly from one setup to the other and calibrate before the next take or setup. The reconstruction of the data capture is an optimization problem where rays are bundled, and the intersection is calculated such that the re-projection error of the marker in 3D is minimized on each camera….

So, this is technical communication style where the editor can do a service to readers by putting down the red pen and treading lightly upon the words of the engineer, software specialist, or other technical person responding. Largely untouched, this story (when published) was better able to convey the intended meaning of these response sentences because I largely left it alone. The message is more “true” to the speaker, and I think his peers can hear that genuine quality when they read it. So as an editor, I think it’s sometimes ok to back off on making everything fit one style or set of grammatical rules. I am ok with not making everything active voice in my stories. Passive voice is sometimes ok too. It sounds more natural. Too much editing can make text sound unnatural. That’s bad. I want my pieces to sound genuine, the way people really talk and think. So, it can be ok for a content editor to allow a certain amount of freedom of expression. Trying to preserve the ways technical people naturally express themselves is not always good or appropriate. But sometimes, it is better to preserve their technical voices, especially if you are not 100 percent sure you can change the text without losing part of the meaning. Technical brains operate in unique ways. Taking that brain functionality in to account when editing or even writing a piece is good to do because the audience for the technical pieces will have similar brains.

There is a third approach for technical content. I call it the Editorial Guide.

A guide can be someone who is familiar with a certain territory. Knows their way around, whether it’s a fishing guide who is familiar with a lake, or an editor familiar with a particular industry or market.

With a guide, you get to choose where you want to go. A guide can show you how to get from point A to point B or point C. The guide can also advise you on where not to go, and what to avoid.

Editors and content developers can sometimes be guides. It is ultimately the writer’s job to define the informational needs of the audience. However, as a writer and an editor, I’ve also taken the time to ask readers what they like. And although I chose stories to pursue all of the time, I have been swayed by my readers to go after stories I never even thought of going after.