Alison Reynolds Talks to STC Atlanta--
Last night's STC Atlanta chapter meeting was a stimulating event. For one, it was good to be back on the campus of Southern Polytechnic State University seeing old associates in the TCOM department. Alison's presentation on the findings her committee will present at the STC Academic-Industry Leaders Summit on Friday in Houston was insightful and sparked lots of comments about what role academia should play in preparing graduates of their technical communication programs. The turn-out was large and the participation among the group was that of positive engagement and respectful differences. All in all, just what a professional association should provide. Job well done, Alison.

Some of the issues explored included:

• The belief by some that the learning of tools should be an essential part of becoming educated in a profession vs. the belief that academia should not engage in "training" activities.
• The fact that industry talks the talk of being interested in strategic communication, critical thinking, and business skills when discussing what they want to hire, but they advertise for "tools, more tools, and domain knowledge." The problem is exacerbated when HR screeners use tools as the go/no go criteria for screening applicants.
• When academic programs offer courses aimed at the strategic skills industry says it wants, students do not support those offerings by enrolling in them.

One of the goals of the summit will be to see how a cooperative effort from academics, industry, and STC itself can resolve some of these problems.

I am also going to the summit and I will be chairing another subcommittee that looks at how academia, industry, and STC can integrate their respective interests, expertise, and resources in the area of research. Not as sexy as Alison's topic but one that has elicited responses every much as passionate.

Also attending the summit from the Atlanta chapter are Carol Barnum and Scott DeLoach (who is chairing the committee looking at STC support for academe and students). Given that the list of attendees is about 30 (by invitation only) it says a lot about the strength of our chapter that Atlanta is providing 10% of the participants (and 40% of the chairpersons). I bring this up to encourage Atlanta technical communicators to start participating more in local chapter events. And as long as I'm bragging on local talent, I was also proud to see the positive engagement and insightful discussion that my co-workers from IBM Internet Security Systems, Mark Wallis and Miranda Bennett, made during the meeting. I've hit that point in my life and career that I have tried so hard to get to: I'm surrounded by smart people and we are working on important problems.

Now, if only the Tasty China restaurant next to Southern Poly would get a beer and wine license, life would be perfect.

Latest Column in UXMatters--
My regular column came out yesterday in UXMatters that combines several topics I have blogged about lately. It shows the benefit I derived from comments I got through this blog (not to mention Pabini's editorial hand). If you haven't read this online magazine on user experience issues, give it a look.

Atlanta STC Chapter Meeting: 9/25/2007---
The guest speaker this month is Alison Reynolds from Christchurch Polytechnic Institute of Technology in New Zealand. Alison is on her way to the STC Academic-Industry leaders Summit in Houston on Friday where she will chair the committee on Job Skills and Needs. This committee is addressing the following issues:

• What do hiring managers really want: short term skills such as tools expertise or long-term assets such as business knowledge and leadership skills, or both?
• What do practitioners wish academics knew? What basic and more advanced competencies would they like to see in graduates of TC programs? Who might teach/train to these competencies?

I encourage technical communicators in the Atlanta area to attend Alison's presentation at the Atlanta meeting (being held at Southern Polytechnic State University) and enjoy the opportunity to provide your own perspective and input. For times and directions go to www.stcatlanta.org.

The 90 Seconds Rule--
In my previous blog I talked about how users can only stand being in Help (and away from the task they would rather be doing) for about 30 seconds. Nice, round number.

Another rule I find useful is the 90 seconds rule: Users will struggle on their own for at least 90 seconds before going to Help. So don't waste your 30 seconds on something the users will discover on their own in their 90 seconds.

For example, a product I work on has a table of firewall rules, and the user can change the order of the rules by selecting a rule and then clicking either an up or down arrow on the UI. Well, this is a fairly well-used and well-known convention to most software users. But even if it's brand new for some users who want to change the order of the rules, they will figure it out in their 90 seconds of fumbling. How long will a user sit there looking a rule that's too low in a list without saying, "Hmmm, I wonder if this up arrow does anything." So I spent my 30 seconds giving tips and guidelines about when a rule should be higher in the list and when it should be lower.

But what about the poor user who doesn't figure it out? I still documented it as a note in one of my tasks. I just didn't create a big procedure about "Changing the order of the firewall rules."

So another way to keep your Help files lean is to focus on information that the user will not be able to get from experimenting on the UI (which is exactly what they do before going to Help).

The new research primer is here, the new research primer is here...
Older readers might remember the Steve Martin movie "The Jerk." I love the scene where the new phone books arrive and Martin, as the title character, is ecstatic to see his name in print for the first time. Well, the book that I coauthored with George Hayhoe arrived at my house last Friday and the scene was pretty similar. Not the first time in print, but it is the first time my byline made the cover. It's even on Amazon.

It's always the same for me anytime I get something published. Instant thrill (oh boy, time for my 15 minutes of fame) followed by disappointment (oh no, I should have done a better job than this). I'm getting better at staying centered and balanced. The thrill used to be "Oh boy, I'm famous." I realize now that we are all famous, some just more so than others, and even the most lasting of fame is still only temporary. And I know that perfection is a fool's target. I'm content now if my output is good enough to do someone some good. I hope this book helps a student who is overwhelmed by having to do a research project, or some practitioner who would like to be a more critical consumer of research. I hope it helps shape research agendas that define our practice for the better.

As Buddha said: Before enlightenment it was chop wood and carry water; after enlightenment it is chop wood and carry water. OK, I've got a research textbook on my shelf with my name on the cover; time to get back to work on the Help file I'm writing that tells users how to back up their log files.

Still, it's a lot of fun to see my name on the cover of a book, and oh, I wish I had done a better job.

Not All Questions Are Hard--
During a walkthrough last week of some Help topics I had written, my colleagues and I were discussing when to put a link in a step in a Help task. We dislike sending the user to other topics in the middle of a task, lest their Help experience start to look like one those Family Circus cartoons where little Jeffy's footsteps can be traced across the entire neighborhood several times and back. The particular problem I was trying to deal with was a situation where I felt the UI was asking the user to make a tough decision (what kind of encryption algorithm did the user want to use) and I could not do justice to the choices within the confines of the choice table (option/description) we typically use in our steps. I felt the need to provide an in-task link to a reference topic that compared the three algorithms we accommodate.

But then someone asked an interesting question, "Are we asking them to decide or are we just asking them to tell us what they already use?"

Wow, does that make a big difference in what the Help has to provide! I've always been big on the fact that Help should support user decision-making when forms have to be filled in. For example, it's not enough to tell users what the upper and lower limits of a parameter are or list the choices available, Help should assist them pick an appropriate value or make an appropriate choice. But my problem might be that I'm treating all fields as if they are decision fields.

For example, if a form asks which type of email client you are using and offers two radio buttons labeled POP3 and SMTP, does the Help have to define, compare, and contrast these choices? If the user doesn't know which one he or she is using, does knowing what they are make it any easier to select the right button?

As basic as this might seem, it is a point I have been missing and adds an important question to my task analysis, "Is this screen asking the users to make decisions or just provide information about their environment?"

In a way, it reminds me of the Family Circus-like joke about the boy who asks his father "Where did I come from? " The father sweats it out and gets through the whole birds and bees thing only to have the son retort, "Well, Jimmy says he's from Ohio and I was wondering where I came from."

Not all questions are hard.

Email vs. e-mail--

I got involved in a debate this week over email vs e-mail. Our UI says "email" and our documentation style guide says "e-mail." Editor's decision was to say "email" when referring to UI text and "e-mail" when talking about the topic. Good decision, but what I found interesting was the discussion about the usage. One writer favored the use of "email" saying that "e-mail" seemed outdated and that we should allow the language to evolve. Anyone who has read my blogs knows that I am all about letting the language evolve, therefore I found it interesting that I was on the side of "e-mail." It gave me pause and made me think. (I like talking like that in blogs because you sure can't talk like that in a Help file, e.g., "Error 404 file not found: Certainly gives you pause and makes you think where the file could be.")

I AM all about evolution of the language, but there are two sides to evolution: The weak and useless go away, but the strong and useful persist. My colleague's reasoning was the compound words tend to eventually lose the hyphens after a period of acceptance, and I think that is an accurate description of the evolutionary life cycle of most compound constructions: two closely associated terms become a hyphenated term and eventually the hyphen goes away and leaves one word. Black board becomes black-board which becomes blackboard.

But the situation under question is a special subset, one in which one of the elements of the compound expression is a letter that stands for a word. I can think of no example where one of these has evolved into a single word. Examples include c-section, t-bar, i-beam, a-bomb, b-school. Many of these terms are much older than e-mail and their hyphens are still intact. The law of language evolution would indicate that the hyphen must be useful in this pattern or else it would be eventually disappearing over time (which it hasn't seemed to). Try reading these words without the hyphen and I think you'll see that the punctuation "earns his rations" as we would say in the army.

Csection, tbar, ibeam, abomb, bschool are awkward constructions to process because our initial instinct is to see them as letters and not as words.

So I am not the linguistic anarchist some of my colleagues fear me to be, merely a pragmatist. As professional communicators, we should throw away the useless bete noires (use that in a Help file), but we should also preserve any aspect of language that adds precision or facilitates processing on the part of the reader.

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?

Maturity or Bureaucracy?--

In his latest Alert Box, Jacob Nielsen talks about the pros and cons of developers doing their own usability testing. For a while, now, Nielsen has had a maturity model that basically states the more mature an organization is about usability, the more independent the usability function is within that organization. Therefore, developers doing their own testing is an indication of low maturity.

I disagree. One of the most mature organizations I ever worked at from a usability perspective was CheckFree Corporation. For one, the concept of ease-of-use was embedded in their corporate mission statement and they had their own usability lab. The lab was run, however, by designers in the UX department. These folks were part of the Development organization and their main deliverable was not test reports; rather it was the wireframes from which the development team coded the product. A salesman for an external lab once asked me how I sold my usability value within the company. I told him I didn't, the only reason I did usability testing was that I wanted the data to see if my designs would work before the marketplace provided that feedback. My company valued my wireframes; I valued the data that informed those wireframes.

Still, there persists this popular belief that usability has really made it when it is an independent department in a company. To me that's like measuring the maturity of an engineering company by whether or not it has an independent department for doing the math. It doesn't make sense for engineers not to do their own math, nor does it necessarily make sense for designers not to do their own usability testing. To say it is not in their basic skill set merely sets up the question, "Why the hell not?"

About 25 years ago I was managing a training department when my company was making the transition from having a department secretary who typed our video scripts to having the instructional designers use word processors. There was almost a mutiny. Today, we see word processors as cognitive tools, things writers use to help compose and organize their thinking--not merely as output devices.

Usability testing should be the same. It shouldn't be something we send over to the usability pool to have done by "those people." It should be a routine task in the course of doing design.

Call Me Tina--
Apologies to Holly Harkness for the pun on her blog title. I was chatting it up over wine with my mentor and friend Carol Barnum last night at an alumni social and happened to mention that after my varied career in a number of aspects of user-centered design (usability, training, performance support, UX design) I was happy to be back in the core field of technical writing and user assistance in particular. Carol seemed surprised at that, and given all of the buzz over the last couple of years about how we are so much more than technical writers and how we are moving on to sexier roles, I guess I am somewhat of an anomaly. I was making it in the big city and chose to move back to the farm. We talked a little bit about why.

Putting on the Sneakers
At the heart of it, I suppose, is that I like to write and I am trained to write. Information design and writing are my core skills. So I am glad to be back in my sweet spot. As a UX designer, I was always behind the professional power curve of the likes of, say, a Luke Wroblewski, or in usability trying to keep up with such luminaries as Jared and Jacob--not to mention Carol. Technical writing might not be the biggest pond, but it is one in which I know how to fish pretty well, and there is comfort and reward in that.

The less obvious but maybe more compelling reason is somewhat counter-intuitive: In spite of all of the obituaries on technical writing, it has the greatest job security of all of the fields related to user-centered design. In spite of its being often maligned, Help and other product documentation are must-haves, check-off points in the the product bill of material. Companies don't want to spend a lot on it, but no product manager is going to say, "Let's not offer Help with this application." Companies whose products lack usability can still believe they have it. Not true of documentation. If you don't have it, you don't have it.

The down-side, of course is that companies don't want it to cost a lot, so documentation departments get downsized a lot or doc gets off-shored. For one, I think the off-shoring of customer-facing documentation is a short-lived experiment that shows many signs of failing or at least stabilizing due to supply-demand equilibrium.

Well, what about cutbacks and layoffs? It reminds of the story about the two guys running from the bear. One stops to put on his running shoes (sneakers if you are from the South and older than 50), and his friend says, "Those won't make you faster than the bear." The guy counters, "I don't have to be faster than the bear, I just have to be faster than you."

The point is (yes, please, Mike, what is the point?) although good writers get laid off, they don't get driven out of the business. Keep actively pursuing excellence through education and professional development and you will stay ahead of those who don't. Those are the ones the bear gets.

Dressing Like a Grownup--
Al Hood posted pictures from the STC conference recently on his president's blog. There was a picture of me "on Mike's one day to dress like an adult." I actually had on a tie and sportscoat because I was a keynote panelist for the opening ceremony.

Well, I'm dressed kind of like a grownup again today, no tie, but an Izod golf shirt, khaki slacks, sports coat, and leather loafers. I'm going to the STC meeting tonight.

Normally I wear shorts, t-shirt, and sandals to work. What's interesting about that is that I work for IBM. When we (ISS) got acquired by IBM, we asked if our dress code would be affected. Their reply was interesting:

Thomas Watson, IBM's founder, established the white shirt, blue tie, blue slacks look because he felt that "IBM people should look like our customers," and in those days, IT folks and accountants looked like that. Well today, our customers wear shorts, t-shirts, and sandals; so I'm right in step with founder Watson's philosophy.

It makes me wonder, though, as a technical communicator, how else have my readers changed over the years, and what archaic misconceptions might I be dragging around with me? Is the user in my user-centered approach to designing documentation still around, or did he retire years ago? Is he now wearing sandals and t-shirts while I'm writing for wing-tips and ties?

If users shift from being task-oriented, for example, to being concept oriented, how would we know? In fact, I suspect they have. A lot of our conventional technical communication wisdom predates intuitive user interface design, dashboards, and such. We still document GUIs as if most of the world still wonders how radio buttons work.

At my last job, which dealt with online banking, one of our sponsors commented that the Internet and email were becoming the technology of "our customers' parents; the new customers want to bank by Blackberry and cell phone."

The whole persona of the user who is intimidated by technology and befuddled by arcane interactivity--in short the user of my user-centered world--is probably going away (gone away?). To paraphrase Pogo, "We have met the user and he is us," is the downfall of all designers. We design and write for ourselves in the belief that our users are like us. Or we write to someone as they were twenty years ago when we first started studying them.

What if they grew up?

Dagnabbit!--

I'm just too old for some of the new design trends, and I'm starting to mutter at my PC sounding like my Aunt Hattie (bless her heart). I'm back on my soap box about how affordances are going out of vogue with interaction designers in favor of pliancy. One more time in English:

Affordance is the quality an object to look actionable by the nature of its appearance. A graphic of a button with the word Submit on it has a lot of affordance. The convention of underlining a link and putting it in color is so ubiquitous that it has become an affordance.

Pliancy is when an actionable object changes appearance when you mouse over it.

I was on Boxes and Arrows (a premier site on design), and I wanted to read the article "Comics: Not just for laughs!" in the snapshot above. I kept clicking on the author's name, and I kept getting a bio of the author. Finally I moved my mouse incidentally over the name of the article and voila! it turned red and was underlined.

Why does the most important action a user would want to take (open the article) not have an affordance while the links to the author's bio and comments on the article have them?

This is like so Web 2.0 where the user is expected to explore the page in order to discover its functionality as if it were a PlayStation game. I'm feeling ancient.

I know, don't talk, Mike, with your mouth full of Metamucil.

Holly's Back--
For those who missed Holly Harkness's transition from her President's blog, her new blog is: http://dontcallmetina.wordpress.com.

Just got back from a week at the beach playing with the grandbaby and mastering boat drinks made in a blender--IOW, feeling pretty calm and mellow.

There are a couple of reviews of this year's STC conference on UXMatters .

I wrote this one: http://www.uxmatters.com/MT/archives/000197.php It's pretty positive, but I do imply a certain industry guru is standing in elephant poop based on a comment he made in his blog.

This one takes the conference to task, but did have nice things to say about my presentation: http://www.uxmatters.com/MT/archives/000196.php

All in all, minor quiblings aside, all views seem to point to exciting possibilities for our profession and how it is converging with other user-centered disciplines. We are writers, hear us roar, kind of stuff.

New Column--
Please see my column in the current UXMatters. It is called The Anatomy of a Help File and discusses how user-centered Help can be developed iteratively.

Patterns for Interviewing SMEs--
At this year's STC conference, I attended a presentation by Larry Todd Wilson on Knowledge Harvesting. Larry is a knowledge management consultant who specializes in capturing knowledge from experts. Larry talked about patterns of interviews he would use, based on the situation he was in. One pattern that seemed appropriate for investigating software application screens that serve as status or dashboards was this one:

1. What is the intent of the screen?
2. What are its primary objects (what should the user look at)?
3. What are the traits or attributes of the objects?
4. How do you weight the objects?
5. How do you integrate this screen into your decision making?

Another pattern I have found useful for investigating screens that require the user to enter a numerical parameter is the following:

1. What's a good starting value (or what influences the starting value)?
2. When would you make it higher?
3. When would you make it lower?
4. What happens if it gets too high?
5. What happens if it gets too low?
6. What indicators (e.g., reports) would you look at to evaluate if your choice was too high or too low?

I think as an industry, we would be well-served if we could categorize a set number of patterns like this to help us interview SMEs. If you have any useful patterns, please send them to me and I will share them.