bravo to Chrysler's

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/

GUI based application help

I started responding to this article about not include screen shots in GUI documentation. Then I went off topic so I'll just post my thoughts.

The problem of managing screen shots in GUI application documentation has dogged me starting 15 years ago - fresh out of college and a new tech writer.

Creating and maintaining documentation that includes screen shots is a nightmare. I'm surprised that GUI API suites haven't created a tool to make images and image regions structured. Pairing that with an authoring application that understood such structure and could apply style rules to the interaction of the master document's layout could help.

Actually, when you think about it, it's crazy that we document on-screen procedures in a separate paper-document or window. I'm sure those of you who write docs for GUI based applications on a daily basis think about this all the time.

An alternative is for help to be delivered as an overlay/layer over the GUI. that would be sweet.

Anyway what I'm saying is we don't have the tools for the most helpful Help/documentation. It's a minus for the user and tech writer. And that's sad considering that GUI based applications have been in widespread use for 20 or so years.

Maybe someone can point me to a well-woven/efficient application+help example. I'm just not aware of any.

documentation nightmares: car seats

I was going to make this post 3 years ago, but didn't. Now I have another opportunity.

I consider myself technically adept at mechanical things. 

• 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.
  

So you would think that installing a car seat would pose no problem, especially after I've had experience, and considering I am a documentation professional. Well, no.

Certainly you want absolutely 0 margin of error for your car seat installation. This is my family's 3rd car seat - the one we purchased this weekend was a Booster / forward-facing-harness seat. And like I always do, I stuck to the directions. And that's where I failed.

Here's the problem as I see it: The pocket-sized, 35-page guide includes procedures for:

• Booster seat operation
  
• Harness seat operation
  

And attaching the seat to the vehicle via:

• LATCH
  
• Seatbelt with shoulder strap
  
• Seatbelt without shoulder strap
  

So that's potentially 6 scenarios. In addition, the text warns of procedures not to follow that may only be applicable to the scenario you are not following. It's confusing, not reassuring, and highly annoying. 

My guess is they cram all this information into a little booklet to stay attached to the car seat, and the lack of clear directions is probably designed so they can CYA, legally.

I don't object to including the product manual as is, but they should publish more refined instructions in a larger format. A nice 2' x 3' poster with line graphics that tells you each step you must explicitly follow would be a great start. In fact, one poster-sized document per scenario would be very good.  Personally I think the best solution would be for their documentation to interface with a database of car specifications. You could go to the website, choose the car seat model, choose your car model, and their system would automatically generate the documentation you need.

(Image courtesy of  dfb)

tech writer job security

I think these days every worker is looking over his or her shoulders for the proverbial pink slip**. While companies are probably going into hibernation mode, let's remember how important documentation is.

A complete product includes documentation. It might be a formality that people like to laugh at, but it is a requirement. Wise management, under economic duress, will cut development in step with documentation (and sales, and marketing, and support). Very few organizations will purchase a complex software product without a sufficient doc set.

Wiser management will realize that excellent documentation can offset a support staff. 

I've heard the stories about how the technical publications departments are the first to go, but I have a feeling they're exaggerated. And if all the writers are sent home first, as a barometer of the company's health, the whole development staff is not much behind.

** note: a simple way to stay somewhat sane is to NOT read economic blogs. they will scare the heck out of you.. ask me how I know :(

detailed concepts

The following thoughts were initiated by reading this great post by Alan J. Porter on how traditional structured content is losing primacy.

Structured and formal content is not going anywhere. It is probably still as important to our ways of exchanging, archiving, and mutating ideas as ever. The rise of the web, of so much of the whole of human experience available to us at any moment has initiated a period of people using more content than ever before. But it's that smaller pieces of content are being used in exponentially greater amounts. 

I'll give a quick example that shows where this is happening. Let's say there's some new drug on the market used to treat farsightedness. pre-web there would be research building on theory, and then clinical trials, followed by approval, marketing, and use by the general public (ok this is totally out of my league, but I'm just throwing out an example).

Now, the process and documentation of bringing that drug to market were extensive as everything is required to be captured by law. Later, an interested individual would learn about the drug either through their doctor or a friend or advertising. If they had questions, they could ask those people, or maybe find information in some reference guide. Tho' it's unlikely that they could find truly detailed content unless they took up the search full time (or knew how to navigate pharmaceutical/medical references).

Today, all of the references are easily available to us. Personal stories about drug therapies are available to us. One can start reading and reading, and if necessary cross reference relevant technical literature, ignoring the bulk of the published literature. Without wading through the mountains of data you could search and find information on drug X and high blood pressure. 

Certainly in the pre-web days this information was available, but it might be pretty difficult to find. The web has enabled more people to access this information directly, leapfrogging all of the background or supporting words that only an expert would have consumed.

I believe that we must be cognizant that some of our readers are just looking for small nuggets of information; tho' this audience may only find what they're looking for with a search engine, and they would never use an index. 

Maybe a good question for the experts to consider is how DITA and other structured formats can optimize their content for search engine crawling and successful hits on a given query.

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.

I love the technology, but for several years the web has been about people and interpersonal communication more than anything, and I haven't really kept up in this realm. 

So the other night Arianna Huffington was on john stewart, pushing her book on blogging. Within 6 minutes time she shed light on why it's so tough for me to gain any traction blogging. 

First she says "blog your passions." Ok that's not too tough. I love to write about I have thoughts and opinions I'd like to share about tech writing, and tech, and media, and music (and their intersections). But then she said how blogging is about getting your thoughts down and firing them off quickly...

Do you know how many draft blog posts I have saved???? I think the TW in me wants to take the time to write down concise thoughts, not leave ideas hanging, and try to direct the reader toward a conclusion (don't you just hate it when you post about X, and the thread goes to some minor point you made in passing that could have just as well been left alone???)

My wife turned to me and said "you even write out your phone calls before you make them!!" (which i do sometimes because I want a precise query).

Perhaps this is where my shortcomings of being a real writer is apparent: Given a controlled topic to write on, I'm good and fast. But given the task of writing open-ended, engaging prose that people want to read and respond to, I fall short.

The Daily Show With Jon StewartM - Th 11p / 10c

Arianna Huffington

Barack Obama Interview
John McCain Interview

Sarah Palin Video
Funny Election Video

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!)

Take a glance at the excellent Writer River. If you read past the headlines, you'll notice that many of the submissions focus on user-oriented writing. I used to read techwr-l regularly, and besides their discussions on the inanities of grammar, and implementing single sourcing through structured languages, the most talked about topic was creating effective documentation through user-centric writing and what it means to be user-centric. 

Another reason why S-O TWing gets the shaft is the more the writing is only responsible to the facts, the more it's feared by the average professional writer. I say this not from first hand experience, but I'm drawing from years of reading technical writers' ramblings. The essence is that most TWers like to engage in the act of writing (which might have been what brought them to TWing in the first place). Yet S-O TWing zaps much of the enjoyable art and craft from the exercise.

There's also no ongoing writing challenge in S-O writing after you get it: once you master the logic of presenting clear, factual, expository or descriptive writing, you've got the craft. What can only sustain you this point is enthusiasm for the content itself.

Like everything, this is not black or white. While I can say that my work is mostly S-O writing, if I said that there are no user considerations, I'd be lying. In real life, my work severely tilts heavily toward being responsible to the content, but I'm still mindful that the reader is trying to get a job done. I'm still going to use transition words to make the reading flow, I'm still going to use visual formatting cues to make the document easy for the eyes to follow, and I still mix up sentence patterns so that I don't present 1000 pages of S-V-O constructions.

One final note: While S-O writing product usually falls into the class of a project's requirement, it's a business formality. It communicates concepts and details for the sake of reliability and sustainability. Using S-O writing for user-centric purposes gets all sticky, but that's the subject of another post.

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
  

This is important to consider and be cognizant of because subject oriented TWing gets comparatively little attention, yet I believe encompasses a huge amount of professional technical writing output. So I'll give my quick, ideologically-pure definition of subject-oriented writing.

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.

So, any time you are hired to document an organization's system, process, or configuration, you are primarily hired to create this type of content. Usually, subject oriented technical writing is a contract requirement meant to capture how the contract was executed. And what's the final destination of this product? Well it ends up on the shelf in a binder, in an archive directory, or on a CD or backup tape stored in a mountainside. No glory for the writer.

Let it be said that subject oriented technical writing is dry by nature; it is not sexy; it is just the facts & perhaps even-handedly considered opinions. As a computer industry writer, let me say that the shining example of this type of writing is the collection of RFCs. 

 

I would guess that something like a tenth of all technical writing is purely subject oriented.