head of technical publications:
Chrysler announced that digital owners’ manuals will replace their paper predecessors starting in 2010. The automaker is the first to switch from dead trees to DVDs, and estimates the move will save 930 tons of paper annually.
read on: http://www.wired.com/autopia/2009/09/chrysler-eliminates-the-paper-owners-manual/
Tuesday, September 22, 2009
bravo to Chrysler's
Monday, May 11, 2009
documentation nightmares: car seats
- Building Ikea furniture? Easy and fast - rarely do I need the directions.
- Fix my car? Sure, I'm at home under the hood and under the chassis.
- Soldering circuits? Been doing that since 6th grade.
- Fear of disassembling anything? Nope not really.
- Booster seat operation
- Harness seat operation
- LATCH
- Seatbelt with shoulder strap
- Seatbelt without shoulder strap
Monday, December 08, 2008
my failure as a blogger
I've been around the block on the Internet. I got my first Internet email account the 2nd or 3rd week of college in '91. To me, the WWW is just one part of the Internet. But obviously things change and mature and I haven't kept up. Which is to say I used to be thoroughly engaged in the culture and society of the Internet, but as we're in post-Web2.0 times, I have lonely facebook, myspace and livejournal pages. My 4 or 5 blogger accounts are mostly stagnant, and my personal website is used as a photo album to share with my family who lives out of state.
Tuesday, November 04, 2008
why the attention?
So why am I ranting about subject-oriented technical writing? Well for reasons of fate, it's the primary type of writing I've done in my professional life. I'm proud of my work, and I'm proud of what good S-O TWing can accomplish. Yet, I feel like it gets shafted in technical writing communities. (hey, my baby is beautiful too!)
subject oriented technical writing
It's been bugging to write down some of my thoughts on a fundamental technical writing dichotomy. Before we can even talk about audience, realize that your documents fall into the following camps (or a combination thereof):
- user-oriented
- subject-oriented
Subject oriented technical writing is only responsive to the topic it documents. It must faithfully and completely explain itself and create new context and explanation where needed. It is legalese in form and does not owe anything to its creator or reader.
Monday, April 07, 2008
steel cage job title championship match
Two disclaimers:
- I acknowledge that these titles are arbitrary.
- The distinction I describe is my own and my thoughts probably represent the minority.
I don't know if this was the purpose of the blog entry or not, but Collin Turner's discussion of a subject matter expert (SME) has helped me make a sharp distinction between technical writer and documentation specialist.
SME is a term that's thrown around loosely (at least in my experience), but Turner starts with a salient point in that an SME "provides needed content." The SME is the source of the content. The documentation specialist then chaperones the content through the documentation process until a product is published.
In my limited world view, I'll suggest the following difference: While neither the technical writer nor documentation specialist creates the product (computer application, piece of hardware, or process) that must be documented, the technical writer creates and is ultimate responsibility for the content supporting the product. He or she performs the requisite research inside and outside of an organization to identify, collect, and organize this content.
Collin Turner's description acknowledges these internal conflicts, but lays the organizational knowledge arbitration at the SME's feet.
When I am wearing my technical writer hat (which I like to wear most of the time), I am navigating my organization and available resources to identify and collect all the required content. This means obtaining different functional organizations' ideas of a product, resolving their differences, and presenting a unified view.** Secondarily, I need to have confidence that I can identify with the target audience in order to create effective documentation from the raw data which I've gleaned. This is a real world description, not some idealistic cut and paste from engineering and marketing documents, fix the grammar and save as perfect documentation dream.
I generally feel that a good technical writer must become competent enough in the subject he or she is writing about to answer most questions about it. In the SME-documentation specialist system, the DS has a place to ask questions, but isn't ultimately responsible for the content.
The biggest problem that I see is when an SME doesn't have a vested interest in the user and doesn't take the time to understand the user's documentation and learning needs. When the SME is an engineer or scientist, he or she is too busy creating the widget. But this system succeeds when the SME is in marketing and understands that his or her success or failure depends on the customer's success or failure.
**Any good TW knows that his or her understanding of cross-departmental viewpoints somehow is really valuable to the organization. If anyone in upper management realized this too, I think that TW's organizational roles could be elevated.
About Me
- Writer Zero
- I'm an old-school engineering drop-out turned kick ass technical writer.