| home | resume | writing samples | contact | |||
The process of producing a manual is a collaboration between the technical writer and the engineering team. Circumstances can suggest variations, of course, but the process usually flows like this:
Also:
Information design is the essence of technical writing. I'll show you:
In
E-mail from the engineer reads, in part:
"The host initiates the acquisition of data from the camera by strobing the ENABLE_GRAB bit of the command register. What happens next depends on how the registers have been initialized.
Out
(Copyright © 1999-2002 by Engineering Design Team, Inc. Reprinted with permission.)
"The host starts acquiring data from the camera by strobing the ENABLE_GRAB bit in the Command register. What happens next depends on the relationship among four bits: CONTINUOUS (bit 4) in the Data Path register, and the hardware trigger bits (0-2) in the Utility2 register. (In the table below, --- means "don't care.")
| CONTINUOUS |
HWTRIG_ CONT |
HWTRIGEN_ FLDID |
HWTRIGEN_ OPTO |
Description |
| 0 | --- | 0 | 0 | Acquire the next single frame. |
| 0 0 |
--- --- |
0 1 |
1 0 |
Wait for a trigger signal from the user, then acquire a single frame. |
| 1 | 0 | 0 | 0 | Acquire all subsequent frames until CONTINUOUS is cleared. |
| 1 1 |
0 0 |
0 1 |
1 0 |
Acquire a single frame for each trigger signal from the user, until CONTINUOUS is cleared. |
| 1 | 1 | 0 | 0 | Undefined. |
| 1 1 |
1 1 |
0 1 |
1 0 |
Wait for a trigger signal from the user, then acquire all subsequent frames until CONTINUOUS is cleared. |
| --- | --- | 1 | 1 | Undefined: specify only one hardware trigger source." |
When time is tight, we prioritize.
The core of a good manual explains the main ideas, then provides a tutorial showing how the interface lets you manipulate them. I've researched and written such a manual in less than a month. It had a preface, table of contents, installation instructions, glossary, and index as well. In three more weeks, I added troubleshooting information, a user interface reference, and significant additions to everything else except installation.
In fairness, I must mention that the format was in no way exotic, and drafts turned around like lightning.
Remote projects require everyone to be a bit adaptable, but they feel like life as usual by now. If you can conduct reviews in an agreed-upon time frame and remain reasonably accessible for questions, I can write you a good document on time.
Sure, if you're in the Portland, Oregon metro area. For extended contracts, I may need some help with workstation ergonomics. When writing long pieces from scratch, I'll probably work at home -- it's more efficient that way.
It's definitely desirable that I do. I'm set up for Macintosh and Windows. For other platforms, we can make arrangements.
I'll need installation instructions, I'll ask lots of questions, and I'll report bugs.
At the moment, my proficiencies include:
| applications | FrameMaker, MS Word, Acrobat, Robohelp, BBEdit, Photoshop, various utilities and e-mail applications |
| operating systems | UNIX, Macintosh, and Windows (current common versions) |
| markup languages | HTML, SGML, nroff, troff |
I've been learning new tools to do the same kinds of tasks -- writing, typesetting, online presentation -- for over twenty years now, and I haven't yet met one I couldn't use. Given the galloping change in high tech, most projects include the need to learn something new. That's fine with me. It keeps things interesting. It seldom slows me down.
My most extreme case of novelty occurred in early 1996: Intel's Indeo® video Web site. I was putting together my first large web site while working with a new operating system (Windows 95®), a new e-mailer, several new editing apps, new technical information (my first exposure to codecs), new procedures, and (last but not least) new people.
The project was done in four calendar months, with slightly over 400 hours billed. My colleagues at Intel were satisfied with the pace.
Not really. I can do diagrams with boxes, lines, and arrows, and anything with tables. More sophisticated figures are beyond me. I made the graphics for this web site, but they use techniques not ordinarily helpful for technical illustrations.
I can work with an illustrator of your choosing or mine.
Short answer: No.
Longer answer: Give me a hundred syntax examples, and I will probably find the ones with syntax errors (though not semantic ones). I wouldn't skip QA on that account.
If a tutorial needs a running application, I cannot write it. The pinnacle of my programming prowess is a feeble JavaScript menu bar. I got an A in Pascal in 1984 and decided I did not want to spend the rest of my life catering to a fussy compiler. The world struggles with enough mediocrity. Few writers can explain technical concepts the way I can. Improve the universal competence level: hire me to write, not to program.
The job is large, complex, and difficult. The client wants my best.