Blog Otro--
I decided I need to learn Spanish (again-I've decided this about three times now). This time I think I'm going to make it. Why? Thanks to technology I am able to enjoy total immersion within a culture from the comfort of my couch and desk. I watch the news on Univision as I have my morning coffee, and I listen to CNN en Espanol as I drive to work. And most importantly, I've started a blog on Univision.com. http://mipagina.univision.com/mikehughes.
Be sure to visit my alter-ego (as if my one ego wasn't enough!) Between all of these tools plus my translation applet on my Google home page, I'm set to be bilingual in no time.

So the next time you see me, just say Hola! I'll know what you mean.

A Newsy Blog--
Al Hood announced at last week's STC meeting that I am the "Atlanta Conference 2009 Planning Committee Chair." I remember shooting my mouth off that we needed such a committee. Holly Harkness and Al swear I volunteered. (Personally, I think everybody else took one step back.) On a serious note, I think the 2009 STC conference being in Atlanta is a great event to spur us to re-invigorate our Atlanta chapter, and I'm eager to get some folks together and help make that happen. So avoid making eye-contact with me in the next few months, otherwise you will be chairing a sub-committee. (The COOLEST one will be to organize and man our promotional booth at next year's conference in Philadelphia.)

I have a new column out on UXMatters discussing the benefit of collaborative walkthroughs with user assistance. Give it a read when you get a chance.

I'm on a team right now that will be taking our new user assistance design out to the usability lab at Southern Polytechnic State University next month. They have a great lab out there, and I encourage technical communicators to get more involved in the usability of documentation. One of the most important problems we still need to understand better is the conflict between our desire to produce complete documentation and the user's reluctance to get off task for too long. We are hoping where I work to start a long-term research relationship with SPSU to help us understand the roles user assistance can play in the context of solving problems within software applications.

One more sales pitch: My new book A Research Primer for Technical Communication that I coauthored with George Hayhoe is due out today! OK, it's no Harry Potter, but I do think it demystifies research and sets a practical agenda for defining best practices within our profession. Give it a read (and support my granddaughter's college fund).

Encyclopedias do not user assistance make--
One of my colleagues attended an internal training session last week so she could observe how our documentation is used by people doing realistic tasks. Her observations were not surprising, but bear repeating:

• Users had a lot of knowledge already.
• Users tried to solve problems using no help. They started [doing the primary task] without consulting any documentation.
• Users rarely looked at the guides or quick start cards. Documentation was the last resort.
• When using documentation, users gravitated toward the diagrams.
• Users got frustrated when they saw how many documents the [product] has on [our customer support] website.
• Users did not use the Help button on the user interface.

I'm not discouraged by these observations, mainly because they reinforce what I already knew. But it was good to be reminded and to think about their implications for product support documentation:

• User assistance has to be useful in small chunks (users don't want to spend time in documentation).
• User assistance has to be specific (users are there as a last resort and will abandon general discussions).
• Information developers should influence text on the UI (since users rarely summon the hidden Help files).
• Information developers need to emphasize informative graphics as much as they can.
• The user interface needs to provide a more compelling access to Help.

In short, Help designs and content development should be less concerned about being complete and in depth and be more concerned about being relevant as soon as possible. Time and time again I see that users go into the documentation as a last resort and when in the documentation, get back into the application as soon as they can. Help needs to look and act more like a performance support system and less like an encyclopedia.

Do the following quick audit:

• Pick any spot on your UI and imagine a likely question the user would have. Click on Help and have an associate start counting out loud--very loudly. How long did it take to get to the answer? How many clicks? Did each click add value?
• Does the Help add value beyond what is already on the UI? In other words, if all you have to say about the customer name field is that's where you put the customer's name, why bother? Seriously, we don't have to fully document our products. Nothing hides useful information better than surrounding text devoid of meaningful content.
• How much of the user's time does your documentation waste by talking about itself? I know your English teacher said to start a chapter by describing its purpose. But I have never seen a user go into a manual to answer the question, "What is chapter two about?" And please, if you take up any space explaining your typographic conventions, users do not care!
• Do you provide meaningful examples or practical guidelines?
• Do you use informative graphics?

Help needs to be quick and relevant. If a topic needs to have the users spend more than thirty seconds, it probably doesn't belong in Help. Because they won't.

John Carroll in the Nurnberg Funnel made the point that training had to accommodate how users really learned. Help has to accommodate authentic user behavior--precisely those behaviors that my colleague observed. Given a choice between re-engineering the user assistance and re-engineering the user, you will be more successful in the long run doing the former.

Product Names--
I was helping my wife this weekend brush our dog's teeth. Yes, that's the level of quiet desperation my weekends have gotten to. She brushed and I held. As it was, the dog was pretty calm throughout--probably helped by the fact that it was chicken-flavored toothpaste--so I thought I would read the instructions on the toothpaste bottle, if nothing else as a professional courtesy to the technical writer who had authored them. (A dying profession indeed, Jared Spool, may doggie breath afflict thee all thy days!)

Actually, they were pretty useful, even including a tip to let the dog taste the toothpaste first before going in with a glob on the included brush/finger-mitten. The only problem was that the marketing department had apparently insisted that the writer use the full product name when referring to the toothpaste--and it was a looooonnng name. Seriously, it wrapped half-way around the bottle. Something like PetProper Canine Oral Hygiene Conditioning Paste. I had to read that three times in one paragraph, each time having to rotate the bottle to take it all in.

I'm having a similar problem at work, we have to reference our product in our Help topics, because they are shared with a larger Help file, and the reader needs to know what product each topic refers to. I understand, but why do product names have to be so big? I won't even tell you about the full name, but the SHORT name is going to force users still on 800 x 600 to scroll horizontally!

Solution
Here's the answer. We've all seen the cavemen guys on the Geico commercials, right? These guys are pretty articulate, but they're still cavemen. So they would be masters of monosyllabic speech. Marketing should hire the cavemen guys to name our products. That way, we would have names like "Ug" and "Mook." Easy to type; easy to read.

Or we could tell marketing that Help readers have already bought the product and ask them to give us easier substitutes.

Personally, I'm holding out for the Geico cavemen.

Timberline Hitches and C++
Just went camping for three days with an old high school buddy, who happens to be an experienced scout master and an all-around great camper. He insisted on teaching me how to tie a timberline hitch. He said it was an essential knot and came in handy if you were going to drag a log with a mule. I reminded him I didn't have a mule.

I tried to sign up for a course on Java programming once, but all of the ones I found required the C++ course as a prerequisite. The rationale was that the principles for programming in C++ applied to Java as well. I wondered why they couldn't teach those same principles in the context of Java and not make me take a five-day course in a language I was not interested in.

I'm sure that the timberline hitch was an invaluable knot for pioneers and farmers clearing off land, just as I'm sure that C++ is a really spiffy programming language. I just don't think that I need to know either of them. So why are some insisting that I do?

It comes down to this: "Dammit, I worked hard learning this, and now you're going to sit and listen while I teach it to you."

I think I do the same thing sometimes to my documentation readers. It took me a long time to master some nuance of the software I'm explaining, and dammit, they're just going to have to sit and listen.

Then I wonder where they went. Well, this is for you and the mule you rode into town on--what do you mean you don't have a mule?