STC Summit

The original title was supposed to be "I Rolled Holly Harkness" after I gave Holly my dinner roll at the Honors Banquet, but that seems too indecorous now that I am in a more sober mood (well, actually, now that I am sober). It's not so much the improper innuendo, mind you; it's the use of a noun as a verb that I find most problematic.

I would be just lying through my teeth not to admit what a great time I had at the Honors Banquet being inducted as a Fellow in the society. I can only say that it is a thrill mainly because I hold my fellow STC members in such high regard and consider our profession to be truly important. Barrie Byron was kind enough to send me a picture of my special moment.

The conference was great, Philadelphia was a delight, and I am exhausted after 2 days of board meeting, a leadership day, and three days of conference. Atlanta folks, be sure to attend our next chapter meeting when conference attendees will report on the conference.

I am also proud of how visible the Atlanta chapter was at this year's conference--Robert Armstrong was Track Manager and Coordinator for the Producing and Publishing Information Track, our chapter won a Community of Excellence award, and Al Hood has taken on a significant volunteer role with the Leadership Community Resource. Holly, Robert, and Al attended Leadership Day on Sunday along with our president, Howard Speck, and our 2nd VP, Jen Collier. Margaret Cekis, Holly Harkness, Al Hood, and I were presenters--I'm sure I missed someone in that list, sorry.

AND, we are the host chapter next year and will get cranking up on that real soon.

So I am back home, both exhausted and rejuvenated at the same time. We live in an exciting time where our profession can have a real impact on what's happening in the world and in the marketplace, and where we can have a real impact on our profession. Go STC!

Patching up the crack...

Ok, you have to be pretty old to recognize the context of that reference. It's from the theme song to Disney's David Crockett series: "He patched up the crack in the liberty bell." I'm all packed and getting ready to go to the airport for Philadelphia and the STC Summit. First I have a two-day board of directors meeting, a one-day leadership day orientation and then the Summit. I will be speaking on Tuesday from 3:00 to 4:00 on how to use Excel to compare averages for statistical significance. It can be useful for comparing quantifiable data (user ratings, time to do task, etc.) between two products, two versions of a product, or different groups of users. It's a little dry, but I make up for it by talking very loudly.

Speaking of context, I stirred the pot a bit in my current column in UXmatters. Partly due to its reference to culture and partly because I advocate against the need for documentation that explains the obvious. Lots of comments. Please look at the column and weigh in if you want. David Farkas came to my defense-I'm cutting it out and putting it in my scrap book!

I've redesigned my blog site to contain links to my publications. This is in anticipation for dropping my web page. I'm trying to follow Sarah O'Keefe's 80/zero rule. Get 80% of the functionality you need for zero cost. So I'm going with all free hosting and services. It's kind of like being a cyber dharma bum.

If you are a reader of this blog and you are going to the STC Summit in Philly, please look me up and say hi.

Just a brief, newsy blog to keep my I'net pipes running.

Two great blogs to check out:
http://dontcallmetina.wordpress.com/2008/05/20/future-doc/ Holly Harkness's blog Future Doc is a rich summary of a speaker she heard. Very provocative.

http://www.mirandabennett.com/onwriting/?p=20 See Miranda Bennett's blog on Translation Phase 2. Need a teaser? Phase 1: Collect underpants.

My column in UXmatters is my take on Jean-Luc Dumont's road sign presentation he did at Currents and how I think it applies to writing user assistance. http://www.uxmatters.com/MT/archives/000292.php

Lastly, now that I am teaching a summer course in research in technical communication (shamelessly requiring my book as the text), I am reminded that Education is the only business I know that gives all the good parking spots to the employees and makes the customers walk.

There, that should have my I'net pipes running clear.

Step Results: Clutter vs. Assurance

Sometimes a result statement in a step just adds clutter and annoys the readers (if not out and out insults their intelligence).

Example

1. Click on Print Properties. The system displays the Print Properties dialog box.

Always useful in case the user wonders what this box is that just popped up that says Print Properties.

Most user assistance writers use result statements sparingly, but there are situations in which they are very valuable:

• If the user might be unsure what action the system will take and that uncertainty could make her reluctant or anxious to take a step
• If the system does something significant in the background that the user will not be able to see

Examples

I had this one today. The user interface had a link that said "Click here to update to version 1.5839" displayed in blue font and underlined in normal link convention. I didn't know if it was a true link or if it was a link being used in lieu of a command button. Was I going to go to a screen that told me what 1.5839 did or would I just launch the update? It turned out that I got a confirmation box and then the update. In that case, the Help should include result statements:

1. Click on the link Click here to update to version version number. The system displays a confirmation screen.
2. To confirm that you want to install the update, click OK. The system installs the update.

Why? Ambiguous UI control.

Result statements can also be useful when the UI is weak on confirmation messages:

1. Fill in the form.
2. Click OK. The system updates the record and clears the current form.

This deals with the angst of suddenly having your data go away and wondering did it go anywhere useful. I think a lot of my data goes to a house in Indiana that has the lightbulb that the switch in my hallway turns on and off. I think some of my singleton socks are there too.

A techwriter dies and goes to heaven...

and she finds herself at the pearly gates before St. Peter. He looks over her record and decides she is worthy to enter heaven.

"We've upgraded our services recently," he tells her, "so that you now have access to a more personalized heaven experience. Since you are a technical writer, I'll show you several versions of heaven behind some of those doors over there that have been expressly designed to enhance the technical communicator's heaven experience."

"Wow," the techwriter replies with excitement.

"The only problem," St. Peter tells her, "is I just got a text message from the boss and I have to handle it. I'll be back in a few minutes and then I'll give you a tour of your heavenly options."

With that, St. Peter steps away, leaving the techwriter standing in front of three doors. Her curiosity gets the better of her and she opens the first door. There she sees a work station with a bazillion-pixel, high def screen, screaming CPU with graphical coprocessors, loaded with all of the latest authoring tools and a high-speed connection to the UWW (Universal Wide Web). She tries a Google search and instead of getting two-million hits she gets just five, and they are the perfect five.

"This is way cool," she thinks to herself.

She decides to see what's behind the second door. There she finds a cosmic Starbucks. Instead of walls and windows, the table are open to the entire universe and you can almost touch the planets and the stars. Instead of paper cups, the coffee is served in deep blue china mugs. She sees a person putting sugar into her latte (in heaven sugar has no calories) when a tiny paper clip walks across the table and knocks on the mug with a sound of tiny knuckles on glass--tink tink tink!

The paper clip speaks, "I see you're trying to sweeten your coffee, can I ..."

At that point the person fixing her coffee picks up the paper clip, takes a rubber band, and shoots the paper clip out into the vast emptiness of space.

"How cool is that," says the techwriter.

St. Peter hasn't returned yet, so she looks behind the third door. There she sees a technical communicator in a meeting room with developers and she is discussing a user interface being projected onto a screen at the front of the room.

"For one thing," she says to the developers, "you've used 'data base' as two words in the title but as one word in the actual screen. Our style guide says database should be one word."

There is a general round of approvals and one of the developers says, "That's why we need technical communicators on the team."

The technical communicator at the front of the room continues, "And if the user doesn't put the right date format in the date field, you pop up a rather cryptic error message. I think you should just put in some client-side scripting that accepts the user's format and converts it to the format the database requires."

Once again, a general round of approvals and someones says, "Of course, it takes a technical communicator to see it from the user's side. We were too focused on the back-end requirements."

And then the technical communicator says, "I have a report from a usability test we did with real users doing authentic tasks with this UI. I can make the results available to you."

Once again, enthusiasm abounds around the table and someone says, "This is why we need technical communicators on the dev team, they keep us focused on the user, and they have real data to back it up."

At this point, the techwriter hears St. Peter returning and she hurries back to the gate.

"Well," St. Peter says, "let's show you some options for your personalized heaven experience."

"Oh, St. Peter," she says, "I can save you some time. I found my technical communicator heaven; it's behind the third door."

St. Peter looks disappointed. "Oh no," he says, "there's been a misunderstanding. That's not technical communicator heaven; that's the door to developer's hell.

The two most common comma mistakes I see good writers make

As hard as it will be for many of my colleagues to believe, I actually know a couple of grammar rules and even advocate that people follow them.

I just finished a couple of weeks of peer editing and saw good writers making similar mistakes, the same mistakes I see good writers make a lot. The problem, I think, is that our brains know the rules but our fingers ignore them under the pressure of deadlines or when the muse is inspiring us with good content. But for what it is worth, here are the two comma errors I see most often (so if you are guilty of either or both of them, you are in good company).

Punctuating compound predicates as if they were compound sentences

A compound sentence has two complete clauses joined by a conjunction. A comma comes before the conjunction. Example: John wrote the user guide, and Mary edited the installation guide. Two subjects each with their own verb.

A compound predicate has only one subject but two verbs. No comma is used. Example: John wrote the user guide and edited the installation guide. If you absolutely long for a comma in the second example, you merely have to add a subject as in: John wrote the user guide, and he edited the installation guide.

Good writers usually make this mistake when the predicate elements are long, as in: John wrote the user guide that went with the latest version of the TurboPro Archiver, and edited the installation guide that went with the X-Level Wiki Mapper for Linux.

Long, but still a compound predicate and no comma.

Separating a two-item list with a comma

A two-item list does not take a comma. You would never write: You can choose option A, or option B. But as in the first error, good writers confuse themselves when choices get wordy: You can assign users to a category based on the permissions you have granted them in Section 10.4, or based on the profiles you establish in Section 14.6.

Long, but still a two-item list and no comma.

What is getting in the way in both examples is long sentences and the mythical comma rule of "use a comma when the reader needs to take a breath."

No such rule. No NEED for such a rule. None of us has written a technical document so compelling that the reader forgot to breathe. In my own case it's as if I breathe without even thinking about it. My lungs suddenly get hungry for air and wooosh; it just happens. I don't think I've ever heard of a situation where a reader was found blue and unconscious with those around him saying, "Oh my god! If only the technical writer had told him to breathe."

At any rate, be mindful that our fingers and this mythical rule are out to put spurious commas into the otherwise well-punctuated prose of even the most seasoned veterans among us. Keep a watchful eye out.

I won :-)

Get dressed, we're going to a party

On April 22 the Atlanta STC chapter is having its annual awards banquet. Holly Harkness has gone all out to make it a stupendous evening (by that I mean the food will be good, we're going to Maggiano's).

So here's my question: If you are not getting an award, why go to this event? Here are my thoughts:

• If you only go to church once a year, it's usually on Easter Sunday. It lets you remind yourself what religion you belong to, and you get to see everybody all looking nice. If you haven't been going to STC meetings, this is a good one to go to for the same reasons.
• An awards banquet is about professional excellence. Hey, that's why you joined a professional society in the first place. This could be the most important meeting you attend. (And if you're not a member, this is a great way to get introduced.)
• The winning entries are on display. This is the best way to survey what the current standards of "best practices" are.
• You'll be networking with the thought and practice leaders in the area.

Remember when being a tech writer was fun? Join me at the awards banquet and let's have fun again.

Reply versus Reply All

My e-mail inbox is cluttered by something other than SPAM. I am on a number of committees and list servers where I must wade through large amounts of chatter that does not add value, but takes up my time and effort to get rid of. Last week I accidentally deleted an important meeting invitation because I inadvertently deleted it along with this category of junk mail.

Here's what I'm talking about. I got an e-mail reminding me that there is a board meeting this Friday that goes out to all of the board members. That's good. The e-mail asks attendees to verify if they are going to have lunch so that the organizer knows how much food to order. Now starts the litany of emails from individuals saying "I'll have lunch." I get these because the responders click "Reply All" instead of "Reply." (This is just one example of a phenomenon I experience several times a week if not daily.)

STOP IT!

"Reply All" sends your answer to everyone on the original email. Use "Reply All" when your answer applies to everyone, or you want to open up your response to the public scrutiny of the group you are participating in. Who am I to give feedback on who should be eating lunch?

"Reply" sends your answer just to the person who sent you the email. In the example above, only the sender needs to know if you will show up hungry.

And list servers have a sneakier version of the same problem. "Reply" sends the answer to the list server list (EVERYBODY), not the person who wrote the post. That is because the e-mail did not really come to you from the individual; it came from the list server.

I'm sorry for the cranky post.

New Column

I have a new column out in UXmatters today called Placing Value on User Assistance. It's a topic I have blogged on before, but the column has a nice shiny picture as my colleague Mark Wallis would say. Speaking of Mark and pictures, right after WritersUA, Mark let me be his gear monkey while he took nature shots around and up Mt. Hood outside of Portland. Awesome! We went from mossy rain forests to 25 feet of snow in less than an hour.

WritersUA was great. The presentations were their usual high caliber, the vendors just chock full of new features, and the networking as valuable and enjoyable as ever.

Great Currents Conference

I went to the Atlanta STC regional conference, Currents, this Saturday. As always, it was a great professional motivator and a chance to chat with some of our leading technical communicators. And Jean-Luc's final slide was right, I will never be able to look at a road sign the same way ever again. Yesterday on my way to the airport, I saw one of Jean-Luc's favorites:

State Law
STOP
Yield to pedestrian in crosswalk

Jean-Luc's point is that it is strange that we need to be told to do this, as if we would have hit them otherwise, and that we must be told it's the law (as opposed to a guideline, I guess.) Jean-Luc forgets that we are the culture that created the video game Death Race 2000 where you get points for hitting pedestrians.

The reason I was going to the airport is that I am in Portland, Oregon, this week for the WritersUA conference. First Currents and now WritersUA! I'll try to post on the conference this week.

One more thing, on the Portland light rail, nobody checks to see if you bought a ticket. It's the honor system. Kind of a nice contrast to "No running over pedestrians or else we'll give you a ticket."

Instructional Text on the UI

Embedded assistance makes us reevaluate some tried and true principles of information design because our instructions occur within an action-packed medium--an application's user interface. If you think you have trouble holding a student's attention in the classroom, try teaching in a video-arcade. In many ways, embedded assistance has the same challenge.

Having said that, I'm going to shoot you over to a column I wrote a year ago for UXmatters called Instructional Text in the User Interface: Some Counterintuitive Implications of User Behaviors .

News

• Check out Martha Stevens new blog on user assistance. Martha's voice and insights will be a good addition to the blogosphere.
• Currents (Atlanta STC regional conference) starts in a few days. Shout out to my buddy, Miranda Bennett, who will be doing an interesting presentation on collaborative walkthroughs.
• And with the start of daylight savings time, I'm back on my routine of going fishing every Wednesday afternoon after work. Actually, I sit in my kayak on Stone Mountain lake, drink two beers, and smoke a cigar while pretending to fish. I have come to the very serious realization that life balance is important; do you have something you make time for every week that is just for you? (Tip: Scheduling something for mid-week is a great way to break up the work week.)
• Voting for STC officers starts next week. If you are an STC member, vote early; if you're voting for me, vote often.

MOO POPs

I want to discuss MOO POPs early in this series of blogs on embedded assistance (EA) because the concept drives straight to the heart of EA: When and where do we need it?

MOO POP stands for "Moment of Opportunity" and "Point of Pain." A moment of opportunity refers to a state in the user interface when we can intervene and move the user to increase his or her adoption of the product. I wrote an article for the Cutter IT Journal last year about progressive user adoption that talks about the ability of embedded assistance to increase user adoption of advanced features based on detecting user readiness for that advanced feature. For example, a useful feature in Microsoft Word is its ability to automate header content using heading tags in the document, such as making the current Heading 2 the header entry. When would you point that out to the user? If someone is in the act of defining a header, that could be the appropriate moment of opportunity. Imagine a link on the header dialog box that said "Tell me how to automate my headers" and which launched a popup that explained how to do that.

A point of pain is where we anticipate that the user might run into trouble. For example, if we provide a field for entering the name of a firewall rule the user is creating, and the developer points out that the database cannot accept spaces in the name, we can reasonably anticipate that some users will screw up. A simple statement next to the field that says merely "No spaces" will save innumerable instances of error messages popping up. In general, the following situations are good candidates to be points of pain:

• When choices or actions are grayed out (Hey! why can't I do this?)
• When we ask users to make decisions (Did you want DES, 3DES, or AES encryption?--say what!)
• When business or validation rules will lead to likely error conditions

So one of the first lessons in doing embedded assistance is that you do not have to be consistent, and by that I mean you don't have to treat all fields equally. The field that asks the user to type her first name does not need embedded assistance; the field that asks her to create a new password probably does (as in what are the rules for a valid password).

The guiding principle should be "Is there a moment of opportunity or point of pain that justifies taking up room on the user interface?"

In my next blog, I will talk about how to maximize effectiveness and minimize the intrusiveness of the EA entries on the user interface.

Embedded Assistance

I'm working these days on some very exciting projects involving embedded assistance. Embedded assistance (EA) is user assistance that is incorporated directly into the user interface, specifically, assistance that does not require the user to go into a Help file or document. Although most people think of embedded Help panes that exist along the right or left side of the application screen when you say embedded assistance, that is just one aspect of EA--and quite frankly, one of the less important elements. Embedded assistance incorporates any text or communication within the user interface that informs or instructs the user:

• Field labels
• Inline instructional text
• Error or information messages
• Button labels
• On-screen examples
• Hover text
• Tool tips

And beyond this obvious list of element where words are involved, I also include other design considerations such as grouping and sequencing of fields on the UI.

I'd like to give a shout-out to Fred Sampson, a colleague of mine within IBM, for the leadership he has shown in taking me down this path. In the next series of blogs, I will be relating research and guidelines Fred has helped assemble along with tips and how to's from my own experiences helping my division move in this direction.

Why embedded assistance?

Today's blog focuses on why user assistance writers should shift their focus from traditional Help and concentrate more on embedded assistance.

1. Users don't go to Help.
2. Embedded assistance keeps users in their task flow.
3. OK, some users eventually go to Help, but then it isn't helpful.

Users don't go to Help

In most corporate cultures there is somewhat of a dichotomy between working and learning. By that I mean we think of the two as being different activities. We say things like "I won't be at work next week because I'm going to the WritersUA conference." Or when an inhouse training session comes to an end, someone invariably says, "Time to get back to work."

Users see going into Help as being an interruption to work. I used to complain about users who were "too lazy to read the manual" until I started doing usability testing. I then realized that the users were working very hard to get the task done, and they were not going to Help for that very reason, they were focused on the task and that is where they felt they should stay.

Staying in the task flow

The best place to put user assistance is in the UI where and when the need occurs. I like to talk about MOO POPs--no, not milk-based Popsicles, moments of opportunity and points of pain. Understanding where the MOO POPs are in your application is a critical aspect of designing good EA. I will blog on that later.

Why Help is anything but

When I watch users doing a task and then watch when they eventually go into Help, more times than not the Help is not helpful. It's not the writer's fault. See my UXmatters column Stepped Procedures: The Sacred Cow Blocking the Road for an explanation of why there is often a mismatch between the user's question and Help's answers.

Upcoming blogs

Tune in for the next few blogs as I go deeper into the following:

• MOO POPs
• Progressive disclosure (an essential technique for EA)
• How to sell the developers on letting us into the UI

February 29th: Bonus Day!

Every four years something remarkable happens; we are given an extra day. Today is that day; do something with it. Here are some options.

• You probably have the latest Intercom or Technical Communication sitting on your desk. Find a good article in each and read it.
• Your inbox has 476 emails in it. Clean them out.
• Download trial software and play with it.
• Organize the rest of your year.
• Go around the office being extra nice or cheery.

You get the idea. Today is a free day, a time-out from the 365 day grind. Make it special and in doing so make yourself special.

Happy bonus day!

Currents Is Almost Here--
In times of tight budgets (and why are we ALWAYS in times of tight budgets) the Atlanta regional conference Currents is a great professional development bargain for those in the neighborhood. So put March 14th (workshop day) and 15th (sessions day) on your calendar.

The quality of the presentations is world class:

• One of the speakers, Dr. David Yates from Auburn, has an article in the just published February issue of Technical Communication.
• At least four university programs are represented: Mercer, Auburn, Georgia State, and my alma mater SPSU (also the venue of this year's event)
• Speakers from major corporations will share their insights: IBM, Mirant, ComponetOne
• I can see that at least two of the presentations (mine and Carol Barnum's) are part of the 55th conference in Philadelphia.
• STC leadership will be there: Mark Clifford, STC 1st VP (upcoming president in June)-- and local boy 2ndVP candidate will be there kissing babies :-)
• International keynoter: Jean-luc Dumont--just saying his name is worth the price of admission

And the networking is always great. So get your head out of the read-me you're working on, or that configuration guide, and rub shoulders with fellow professionals and talk about your craft. Celebrate your professionalism!

For full details go to http://www.stcatlanta.org/currents.htm

ROI--
Those wishing to go beyond Kirkpatrick's 4 levels that I discussed in my previous blog, can talk about Return on Investment (ROI). In short, does the dollar value of the benefit exceed the cost, and if so, how does it compare to other investments a company could be making? Cutting to the chase, what do companies get for their investment in technical communications (measured in financial terms)?

First, the math: ROI = $Results/$Investment.

You face three challenges when you try to do an ROI justification (or claim an ROI victory):

1. Isolating the effect that technical communication had from what everybody else did. For example, did the Help desk calls go down because the Help was better or because the product's design improved?
2. Putting a dollar value on the benefits. In the case of improved efficiency, this is easy enough: (time saved per transaction) x (number of transactions) x (labor cost). Putting a dollar value on increased customer satisfaction scores gets a little foggier.
3. How does the return get harvested?

Challenges 1 and 2 get a lot of attention in the ROI literature so I'm going to skip them. I think #3 is the elephant in the room that nobody wants to talk about.

The R in ROI is "return" and can occur in one of two ways: Checks coming in get bigger, or checks going out get smaller.

I see lots of ROI examples and arguments around scenarios where better documentation reduces the search time of the user. I know that Information Mapping's web page used to have a calculator program that would help you arrive at the dollar amount for what you could save your company. Let's say you do such a calculation and can show a return of $175,000 a year for an initial training and document conversion cost of $100,000. That's a good ROI. But what do you do when the sponsor asks for her $175,000? After all, she did her bit and forked over the $100,000. Where does it come from?

"Uh, people did more work."

Great, did we charge more for the extra work, is my $175,000 in income? Can you point me to it?

"Uh, well, they were more efficient and did the same work in less time."

Great, did my payroll go down $175,000? Was headcount reduced as a result of this innovation?

And this is the problem with many ROI scenarios. They look great until you try to lay your hands on the money. So what's my suggestion? Don't go there unless you can actually produce the increased savings or income in real ways that can be pointed to. If DITA reduces translation costs, go for it. If you say you're going to make content more reusable, be prepared to see headcount cutbacks in future budgets. Hey, you were the one that said you would be able to do more with less.

Bottom line: Don't get into the ROI game because it makes you sound more business-like. Use it only if you can cough up the bucks when your investor asks, "Where is my return?"

A Model for Assessing Value--
I've been thinking and talking a lot lately about our value as technical communicators. I can see that my thinking has been influenced by my background in instructional design, specificially by Kirkpatrick's model of evaluation. In his model, he states that instruction can be assessed at four levels:
Level 1: Reactions
Level 2: Learning
Level 3: Transfer
Level 4: Results

I think we can easily apply this same model to how we evaluate our communication products as well as our contribution to our sponsors.

To summarize the four levels in the context in which Kirkpatrick proposed them, I put them in the context of a training course on how to correctly operate a drill press. Let's assume the training had been triggered by excessive scrap rates coming out of the machine shop.

1. Reactions. How did the students react to the training itself? This is generally assessed through a course evaluation sheet, e.g., course met my expectations, instructor was knowledegable, yadda, yadda, yadda.
2. Learning. Did the students learn anything? This is generally assessed through testing or lab observations. Students could be obseved by the instructor who certifies them using a checklist of targeted drill press competencies.
3. Transfer. Did the student go back to the job and apply the new knowledge or skills correctly and effectively? Employees coming out of the training could be assessed by the shop supervisor who observes if the they are applying the right techniques.
4. Results. Did the training solve the business problem that triggered it? Did the scrap rate go down?

By the way, Phillips adds a fifth level, ROI, which would compare the cost of the training to the dollar value of the reduced scrap and compare it to other investments that could have been made.I'll blog on that one later.

So let's see how Kirkpatrick's model could be applied to technical communication.

Level 1: Reactions--We see this in reader response cards and in usability tests where participants are asked to rate various aspects of a product or document. Lots of the research done on fonts or layout stop at this level of evaluation, e.g., which document looks more professional?

Level 2: Learning--To me this translates to: If the user read the document, did he or she understand it and did it apply to the task at hand. For example, did the Quick Start card work in the lab when we specifically asked users to use it?

Level 3: Transfer--Oooooh, the toughie. Did users improve their performance in real life based on the documentation? For example, did real patients comply better with their medication protocol when given redesigned instructions?

Level 4: Results--Did we achieve the business goal the document was meant to achieve? For example, did Support Desk calls go down, did medical claims decrease, did user registrations increase on a redesigned web page, did percentage of transactions completed go up, etc.

I think we need to emphasize levels 3 and 4 more. I might be wrong, but I haven't come across a research study on fonts that tested if users completed tasks faster or made fewer errors depending on which font face the Help was written in. (So why do we fight so passionately about it?) So I would like to see research in our field increase its emphasis on user performance. (Level 3)

I would also like to see more discussion about the how better informed, better performing users make positive impacts on an organization's business performance. (Level 4)

Certification--
I have rejected Technical Communication certification for a long time, and I have recently changed my mind. The field of technical communication has had a "We don't get any respect" chip on its shoulder for a long time. I think we have failed to communicate our value in many cases because we ourselves have not understood that value. To our credit, we have evolved from "We produce well-written, correctly punctuated documentation" to "We support user task-based information requirements." In other words, we did a good job of moving from documenting products to supporting what users do with those products (please, I'm using the term product very broadly). What we haven't done so well is understand and articulate how a better-informed, better-performing user benefits our employers.

We hear a lot that we want STC to "tell our compelling story" and I have participated in board discussions about what level of management STC should target with articles about how technical communicators add value. To me, this is like asking our mother to come to school with us and tell the other kids they have to play nice with us (well, not as humiliating, but about as effective). The only ones who can tell our compelling story is us (yes, yes, I know it should have been we, but that sounded too, well, like who we were twenty years ago).

So what does this have to do with certification?

• Certification programs, when done well, focus on employer value. Certification will help us communicate to ourselves what our value propositions are--in terms of value added for employers. Once we understand that value, we become better able to communicate and demonstrate that to our employers.
• Certification can increase jobs within a profession, as employers understand better what value those jobs add.
• Certification can create revenue potential for STC.

So if I get elected as 2VP for STC, I will have 4 active years to work on this. And by the end of that 4 years, my goal would be to have a fully defined body of knowledge in place and a certification program launched that demonstrated multiple levels of competencies within that body.

I have a new column out in UXmatters.com: Hockey Sticks and User Assistance: Writing in Times of Resource Constraints. I blogged on it earlier, but this is a more thought-out (and better edited) version than what you saw in the blog.

I've also updated my web page to include my "platform" for my STC 2VP campaign. Take the STC Campaign-2008 link. In short, my focus as an officer would be to

• Maintain a balanced budget that funds the programs that add the most value for members
• Ensure that our publications and conferences provide the content that helps members do their jobs
• Create a collaboration where members, vendors, employers, and academic communities help technical communicators keep up with the ever-changing demands for tools and technology knowledge
• Support a certification program through STC that helps our sponsors trust and understand our value and that creates sustainable careers for technical communicators

I'll blog more on why I have decided to get on the certification bandwagon after staying off it all these years.

A rose by any other name might have more syllables--
Two blogs in one day! But my last blog was 14 hours and another Board of Directors meeting day, so that's got to be 3 dog days at least.

I annoyed some folks today by referring to what we do as technical writing and by referring to myself as a technical writer. Then I totally blew it by referring to the people who consume what I produce as readers. Seriously, I could tell that I was a major disappoint to them, so it made me pause and think. I have noticed lately that I have been referring to myself that way, not necessarily consciously, but purposely enough to notice that I was doing it. Now that I know I'm disappointing and alarming some folks by doing it, I've decided to reflect and try to understand why I have reverted to these somewhat retro terms.

I think there are a couple of things going on. For one, I'm a little embarrassed by the sometimes pretentious sounding titles we use. My current job title is user assistance architect. I just feel less pretentious telling folks I'm a technical writer. I'm not particularly embarrassed by its more blue collar appeal.

But mainly, I think I am rebelling somewhat against the idea that people didn't respect the job we did because we were called technical writers, and somehow changing it to technical communicators will get us the respect we deserve. It just seems to take our eye off the real ball: When we truly add value and articulate it in real terms, people notice. It has nothing to do with what we call ourselves.

For example, I am aware that businesses need a lot of advanced products and services to support their analysis of data that goes well beyond the need for calculators. But it doesn't bother me that the company I work for that provides all of those advanced needs is called International Business Machine. Nor am I concerned when using an ATM that it was made by a company called National Cash Register. I know their names are somewhat steeped in the technology of their origins, not in their technology or business practices of today. Granted, their names have morphed into acronyms, but they serve as examples (along with the NAACP) that if your actions and results clearly communicate your value, out-of-date names don't seem to be so problematic.

So in the close circle of associates who know my body of work and who see me in my professional environment, I'm going to keep calling myself a technical writer; it's clear, and "writer" is only 2 syllables whereas "communicator" is 5. Plus it's a designation my dog can understand--I think "communicator" throws her. And in my case, it's what I do: I write about technical stuff. I further suspect it's what a LOT of us do.

But I also realize the benefit a name change can have in supporting a changing vision, so I will use technical communication in my public communications--if for no other reason so it quits being an irritant to my professional colleagues.

I'm also going to keep pushing that we focus on defining how we can add real value and quit worrying so much about what we call ourselves.

I Visited the Sausage Factory (and did't throw up)--
Otto von Bismark said, "Laws are like sausages, it is better not to see them being made. " I was wondering if seeing how STC really runs from the inside would be a similar experience. I'm serving as an interim director for the Society for Technical Communication (STC) and I am attending my first board meeting in Arlington, VA. Since I am also running for 2ndVP, this is my first reality check to see what I could possibly be getting myself into. I was pleasantly relieved to see that the process and the environment are pretty sane. (I'm not saying I expected them to be anything else, I'm just saying...)

I am very impressed with the caliber of the STC members serving on the board. I know we're a smart group of communicators, but I did not expect the breadth of business acumen and management skills. I was also impressed with the consultants who reported to the board on several areas of analysis the board had commissioned. One had been done by a CPA who specializes in associations, one by a publications consultant--once again who specializes in association and non-profit organizations--and one by an economist who had done a comparative study of the role of a formal body of knowledge and certification across four benchmark organizations. We also heard some impressive reports from member committees, especially one that had done a similar study of our publications from a more internal perspective. That study dove-tailed nicely with the one done by the consultant.

My impression is that we have a skilled set of professionals in the STC office, a mature set of governance principles, and some exciting challenges ahead of us. The two primary objectives that seem to be emerging are to create a stronger business model that mitigates fiscal risk and to move aggressively to defining our body of knowledge--a hallmark criterion for being a profession. The good part of that scenario is that "fix a broken organization" is not on the list.

So, if elected to executive leadership, I see a clear path emerging before me:

• Continue to improve STC operations that will provide greater fiscal security. (Not that we are in trouble in that regard; it's just that we received some excellent advice about how we could improve.)
• Implement recommendations to improve the effectiveness of our publications
• Aggressively support the Body of Knowledge project

I know there has been some turmoil over the past few years, and I have certainly seen threads of discontent running through some of the forums and blogs. As a profession, we have some great challenges as we see our roles changing, and I think STC is as relevant and necessary as it has ever been for technical communicators. I think the professional and volunteer leadership is as ethical and expert a group as you could ever hope to assemble to meet these challenges.

So I'm going on record: If you are looking for a candidate of discontent (the throw the bastards out platform)--Don't vote for me. I'm pretty happy with what I saw.

And if you've felt alienated or discontented, let's give it a new try. Don't just look to STC to solve our problems, become active and make yourselves part of the solution again.

The Writer with 3 Brains!!! --
Gallia est omnis divisa in partes tres. Anything worthy of discussion can be divided into three parts. As a technical communicator who works a lot in collaborative work groups and who serves on several professional committees, I get to see (and participate in) my fair share of technical communicator fights. I'm beginning to understand that the core of many of these conflicts is that technical communicators have 3 parts to their brains, and most of us have a dominant section (one having a disproportionate influence over the other two) or in some cases a subordinant one (two sections in balance and the third just along for the ride). The analogy is very close to right-brain/left-brain scenarios in that the more we can understand what part of our brain dominates us and what parts seem to dominate others, the better we can understand conflicts (within ourselves and among others) and assemble teams that collectively work with "whole-brain" efficiency.

The Parts
To more easily differentiate this metaphor from the right-brain/left-brain model, I'll divide the writer's brain into rear-brain, middle-brain, and front-brain. Each third respectively represents product focus, process focus, and content focus. (By the way, this is strictly metaphorical and is not based in any way on real brain activity--something I have little experience with.)

Product focus (product in the sense of the deliverable we the writers produce) concerns itself with the mechanics of the document and the language. When we are designing templates, editing for consistency, and making sentences obey laws of grammar, we are engaged in rear-brain thinking. I chose the rear of the brain as the analogy because that's where the medulla oblongata is located. It goes its whole day saying things like, "I'm not sure what you are doing right now, but breathing in and out would be a good thing."

Process focus concerns itself with how communication happens. When we architect what channels we will use for specific tasks and users, plan review cycles, write documentation plans, we are using our middle brain.

Content focus concerns itself with what we are writing about. I choose the front of the brain for the analogy because that is where our personality--who we are-- lives, and the content defines who our document is. As in any metaphor, riding that horse too long is sure to put the ship on the rocks and shut down the show. (First hint of the blog: If you wanted to comment on the mixing of metaphors rather than laugh at it, you might have way too much rear-brain action going on.)

An Example
I think I have an underdeveloped rear brain, which any consistent reader of this blog should have realized by now, and a dominant middle brain. I love information design and architecture, I'm largely indifferent to what I'm writing about, and I'm a terrible editor because I don't value things like formats and language rules unless they are in the immediate context of understandability. When a homeless person tells me, "I ain't got no money," I don't correct his grammar because I understand perfectly well what he is telling me.

There is nothing wrong with having a brain imbalance like this but I need to do a couple of things:

• Realize that when I get in conflicts that the underlying struggle might deal more with focus, i.e., product, process, or content, rather than with logic and rationale. In short, I need to be nicer to and argue less with rear-brainers.
• When putting teams together, I need to try to surround my middle-brain dominance with front-brainers and rear-brainers. In short, I need to make sure I'm on a team with someone who will actually figure out how the product we're documenting works. And I need a good medulla oblongata there as well, someone who takes care of the necessary mechanics.

Sweeping, Unsupported Generalizations
Hey, what's the good of having a blog if you can't just shoot your mouth off and have some fun with it? Here are some traits (some legitimate, some tongue-in-cheek) that will help you spot brain sector dominance.

Rear Brainers (Good and Bad--you figure out which is which)

• Like to design templates
• Worry about presentation issues, e.g., how wide this margin needs to be, how much white space should go above a heading 2, etc.
• Make good editors
• Can suck the life out of meaningful discussions by correcting someone's grammar in the middle of it
• Can bury documentation in mediocrity by insisting that all sections be consistent with the weakest element

Middle Brainers (Good and Bad)

• Help boost a department's process maturity rating
• Create efficiencies
• Like to analyze users and their information needs
• Lose STC competitions a lot
• Say "Whatever" to editors

Front Brainers (Good and Bad)

• Make documents meaningful and useful
• Do a lot of the heavy lifting on a team project
• Insist on sharing every nuance and implication of a technical feature (often ad nauseum)
• Have trouble with deadlines because there is always more to know and say

Conclusion
So where are you on this list? Hopefully and probably everywhere. The point is that we should be more aware of these facets of our thinking and behavior and know when they are helpful and when they are not. Where weak, we should seek to bring the missing factor into the team by recruiting members who are strong in those areas. And when we do, and when we inevitably fight with them, remember we are really externalizing our internal struggles. In other words, I don't fight with my editors because they are too rear-brained; my fight is the result than I am underpowered in that sector. Go ahead and fight, just make sure you fight fair and allow yourself to be influenced by the other.

And don't try to tone down so much if you think you have a dominant sector; rather, work on strengthening your weaker ones.

November STC Presentation Posted---

For those who were not able to catch my presentation on Task Support Clusters at the November STC meeting, here is a Camtasia podcast of it.
http://mschoen.libsyn.com/index.php?post_id=288750

Hockey sticks in Flatland...
The principle is called the law of diminishing returns and its graphical representation is shaped like a hockey stick. Initially there is a sharp increase in the dependent variable for a given change in the independent variable, and then, all of a sudden the curve pretty much flattens out. The point where the steep slope bends and flattens is called the knee.

So what does this have to do with technical communication? Well, my department is heading into a "flat" year, meaning that we are not getting any increase in head count. This can be challenging since we had a couple of replacement positions that now go away, and development is adding headcount, supposedly meaning there will be more products or features to document.

And how does this relate to hockey sticks?

First off, if anyone tells you to "do more with less," hit them with a hockey stick. What you do with less is, well..., less! The point is that if you are going to do less, then you must make sure that you are focusing on those things that add the most value.

And that brings up the most important point: In times of constrained resources you must make sure that when you are committing resources--such as head count, tools, training, and time--you are on the steep part of the hockey stick curve. When you hit the knee, put additional investments on another project.

The independent variables
The independent variables that most writers have some degree of control over are Scope and Quality. The good news is that these are two areas technical communicators are loathe to compromise. The bad news is that when resources are constrained, these areas are inevitably compromised. The only question is will the compromise be a managed one or a random one?

Compromises of scope entail not fully documenting the product. The axis of compromise can be vertical (documentation is shallow in detail but wide in scope) or horizontal (documentation is narrow in scope but deep in detail.) Generally the compromises are made in both axes.

Compromises in quality can occur within two dimensions as well: Accuracy of information and correctness/consistency of language.

Take them out at the knees
In a perfect world, we can estimate our work with great precision and tell folks exactly what we can do and what we can't do. Even in an imperfect world, we can predict along the lines of "I don't know what our exact capacity is, but it will be less this year than last, so we have to cut back somewhere."

And that's where the hockey sticks come in. You must decide how complete you can afford to be and how good it needs to be.

Scope
Start first by evaluating your library. Is every document equally needed? Would the impact of dropping the Quick Start card be the same as dropping the online Help or the Administrator's Handbook? This can get tricky is so far as you have to define impact. I think product acceptance and customer satisfaction with the product are the two biggies, but not always consistent with each other. For example, the lack of Help might hurt acceptance into the market place but not be as critical for day-to-day customer satisfaction.

Next, evaluate if the user is better served with a broad coverage or a deep coverage. Readers of this blog and my column in UXmatters know that in Help my vote goes to broad and shallow. (I don't know where they'll ask for Help, but I know they won't stay in it for long.) Specialized documents might opt for in-depth coverage of a few critical topics. For example, a system admin guide might ignore topics that are common (assuming that a system administrator is familiar with them already) but provide in-depth treatment for activities that are unique to the product at hand.

Quality
How good is good enough? My favorite project management axiom is "Better is the enemy of done." The concept of levels of edit has been around for decades. The knee in the hockey stick essentially is that point at which the user quits noticing. For example, I would hate to send out a document with words misspelled, but I don't know how much extra I would spend to get rid of incorrect uses of transitive versus intransitive verbs such as "An error message displays" or to get rid of comma splices.

The bottom line
No, really, it's the bottom line in my blog:

Are you writing the right stuff for the right folks at a level of quality they will notice? When the answer quits being 'Yes," move additional resources to the next item on your to do list.

New Year's Resolutions---
Getting close to that time of year, so I'm starting my list:

1. I will not whine about anything more than once. (Hey! once is therapeutic, keeps the ulcers away.)
2. I will be part of the solution, or I will shut up (other than the exception allowed in resolution 1).
3. I have a big presence, so I will try hard to be small and make room for others.
4. When the team needs someone big, I will quit trying so hard to be small.

I'm sure I'll think of others.

Social Networking: 3 Lessons---
First off, since my primary audience is technical communicators, I know that the convention is that the numbers 1 through 10 are supposed to be spelled out, but usability studies have shown that digits are easier to scan and read than if the number is spelled out.

OK, social networking. I had a recent experience that personalized the risk companies run when they allow a heightened level of interaction on their web sites. I've had a pretty cozy relationship with a particular vendor over the past several years, contributing articles and testimonials, and even doing a presentation at a national conference that highlighted how I had used one of their products. I was searching their web site about a month ago because I needed to find a paper of mine that they had published, and while doing the search found a snippity comment someone had made about me. The vendor had used a quote from me about a product of theirs that I had helped Beta-test. The quote was on their product release page. Someone, in commenting on the product and the release notification, made fun of me because the quote included my PhD after my name. The comment seemed out of place since it did not deal with the product (the purpose of the forum) nor did it deal with my opinion of the product (which would have been fair game). The comment was ad hominem, that is, it attacked me, the person.

I emailed the webmaster and asked that the comment be removed. No answer. I sent an email to the VP of Marketing and got an answer that it would be removed in a few days. One month later it was still there. I sent a second email yesterday, this time copying the president. The VP answered saying it would be off by the end of day. She was good to her word; it's gone today.

The 3 Lessons
Lesson 1--for the person who made the comment. Professional forums are not MySpace. When we participate in these forums, we need to keep the maturity level above middle school. Stay on topic and add value to the professional community you are participating in.

Lesson 2--for me and anyone else engaging in forums, blogs, or other public domains. I was probably being thin-skinned and took more offense than I should have. Part of going public means you are going to be open to all kinds of criticism. I'm very used to my ideas and my writing being criticized. I guess I was not as prepared for someone to make fun of me because I include my professional credentials in my signature block.

Lesson 3--for companies that encourage customer forums. The VP said that the company was reluctant to edit comments lest they degrade the validity of the forum. I understand that; I even respect it. But when comments about customers who participate get unnecessarily personal, some degree of moderation is called for. If a company is going to operate a company-sponsored forum, it must monitor the posts and step in when folks start making fun of other participants. I have moderated many face-to-face meetings and this is the responsibility of the moderator. I think online discussions demand the same oversight.

There always have been and will be bullies in the school yard, you know, the mean kids who like to taunt others--even when the kids get older and the school yard exists in cyberspace. And we will always need a vigilant grown-up to step in periodically and make them stop.

What Brave New World...
I saw Beowulf this weekend in 3D on the iMax screen. Sweeeeet! It got me thinking this morning about how I would use 3D as an information architect if that effect became available at the PC level.

It turned out to be a more challenging question than I thought it would be. My first inclination was to use it to emphasize text, imagining turning on "track changes in 3D" to see where an editor had changed text. Or to have search terms in a document float above the subtext. But we can already accent that information with color and other typographic effects. Then of course I thought of pop ups and layered windows, but again, we emulate 3D today for these effects. Having a 3D display just makes it look sexier.

Graphs could be cool, as well as typological maps, where elevation of data carried new content, not just a pleasing effect. Yes, graphs would be cool, especially if you could rotate the 3D graph and look at it from different angles. But these are graphic effects, and I'm a word guy. It still left me pondering what would I do with 3D as a writer, other than just make it a sexier alternative to using italics, color, underscoring, or boldface. "Oooh look, the term in this definition looks like it's floating."

How could information design benefit from a 3D display?
Well, let's back up a little and ask how information design benefits from 2D. Most information is rendered in one dimension with letters being combined in a sequence defined by placement along a single axis. You might think of this discourse you are currently reading as being displayed in two dimensions, since your eyes move along both an x and a y axis, but that is just an artifact of word wrap. This entire blog entry could be rendered on a single line read from left to right without losing any information.

Then 2D comes into the picture with tables. The meaning of a block of text takes its context from the intersection of its row and its column. How could a third dimension be added to tables that would add a useful additional dimension for information? Let's build an example:

First, let's start with several one-dimensional documents that discuss the history of several countries. Since they are one dimensional, we structure them as tales told about each country in the chronological order in which the events occur. Want to know what happened in China in 4000 BC? Pick up the History of China document and look in the front. Want to know what happened in Japan last year? Pick up the History of Japan document and look in the back.

OK, now let's make it a 2D document. structured like a table. Each row will represent a country, and each column a century. Want to know what happened in China in the 18th century? Go to the China row and scan over to the 18th century column and there it is. Curious about what was going on in England at the same time? Scan up the column you're in until you get to the England row. Curious in general about if anything important might have happened in that century elsewhere? Just scan up and down that column. Whoa, here's an interesting occurrence in America at that time. What might have caused that? Lets just browse back in that row and look at the 17th century. OK, you get the point; 2D could make comparative history more relevant.

Let's take that same model and add a third axis, one that separates science, art, politics, and religion. We can zoom in and out depending on what aspect of a society we are interested in. Now that would be a cool use of 3D in an information design context.

OK, tag you're it. What would you do as an information designer if you could display your information products in 3D (and allow the user to manipulate the display along all three dimensions)?

BTW, give yourself low creativity points for any rendering of physical space in 3D. That is like so today!

Vendors as Stakeholders--
In my candidacy for 2VP for the Society of Technical Communication (STC), I have been using this blog to develop my platform. My central theme has been that STC should forge collaborative relationships among its principle stakeholders of practitioners, academics, vendors, and employers. In my blog on November 3, I discussed the role of academics, and today I would like to discuss the role of vendors.

The Tool Keepers and Trainers
Whereas the role of academics is to be the keepers of the body of knowledge and to be the educators, the role of vendors is to be the keepers of the tools and to be the trainers. This reveals an important aspect of my perspective on our profession: Tools are an important part of what we do and how we are defined as a profession. We are not merely the writers of content; our job is also to design and build the engines that deliver that content. We are a technology-based profession both in our content domains and in our production and delivery channels of that content.

By vendors, I mean those companies and individuals who sell to technical communicators and whose involvement in STC is largely motivated by a desire to be close to their market. Typical vendors are providers of tools such as Help Authoring Tools (HATs), Desk-top Publishing (DTP) systems, Content Management Systems (CMS), as well as services. These services can range from content translation to consultation and training. Conference sponsors that target technical communicators, such as WritersUA and DocTrain fall into the training and conference arena. Consultants are a more slippery category and I classify them as vendors or practitioners based on who's paying for their services. If the TechComm manager has brought them in to help formulate a CMS strategy, I see them as a vendor. If those same consultants do the same thing but for the director of engineering, I see them as practitioners (operating in a contract capacity).

As I have said in an earlier blog (October 31), I think STC has a great opportunity to bring vendors and academics together to serve the integrated need of helping practitioners build well designed solutions that work (all kinds of puns intended). Currently STC is doing some strong things in this area. Lloyd Tucker, the director of Education, has implemented vendor-sponsored webinars that seem to be very popular (given that the one I tried to sign up for filled up faster than a Hannah Montana concert). The active training presence we see by the vendors at our conferences is another example.

Conclusion
So my position is that tools are an important aspect of our profession. I already know more grammar rules than my readers do. My occasional lapse into using "display" as an intransitive verb or writing "Click on Submit" rather than "Click Submit" is not going to diminish my end user's ability to be successful with the products I support. But if I can't figure out how to use social networking technologies, XML-based authoring systems, and a really good content management system, my users will be handicapped with how well they can get to information that influences their success.

And that is where vendors step in. I want our STC to be a collaborative environment that helps practitioners and vendors connect in ways that make both sides more successful than if STC had not been there,

New Column on UXmatters--
I have a new column out today on UXmatters called Procedures: The Sacred Cow Blocking the Road. It's an updated version of a presentation I did ten years ago at the STC conference in Anaheim. Still topical, however. It deals with the basic mismatches between user behavior and the structure of stepped procedures. For example, procedures start at the beginning, users go to help in the middle.

Atlanta folks, I'm speaking at Tuesday's STC Atlanta chapter meeting. I'll be discussing an architecture called task-support clusters and will demonstrate a tool called Task Modeler during the presentation.

Y'all come.

Works as designed--
I did a webinar yesterday for STC on pattern language for managing usability knowledge. Every now and then I listen to myself during these presentations and hear something in a new way. Yesterday was one of those moments for me. What I said and what I understood with a renewed clarity was that any usability problem can be described as a mismatch among the following three forces:

• What the user wanted to accomplish
• What the user did
• How the system responded

I can now see a strong parallel with John Carroll's definition of the human-computer system as comprising the the user context, the user interface, and the machine's architecture. It is the first item in these two lists, essentially the user goal, that drives the difference between "works as designed" and "this is something we've got to fix."

As an example, I did two searches this week where I misspelled the term I was searching for. One engine returned the message "No results found for usbility." Worked as designed! The other search engine returned the message "Did you mean usability?" Guess which search engine is my product of choice from here out.

Bugs are easy to find and fix. The user failed because the code failed. It's when the user fails but the code did exactly what we programmed it to do that we face usability issues. And it is precisely the fact that the code works is why it is sometimes hard to get people to fix these problems.

The solution is based in Carroll's system definition. The user context is part of the system, and all definitions of success and all test plans for the system must include this element. Error and ignorance are part of the human context and good system designs are programmed to deal with both.

New Picture--
At 58, I did something for the first time yesterday; I had my portrait shot by a professional photographer. I was required to do so because I'm running for 2nd VP of the Society for Technical Communication (STC). In picking the final one I would use for my candidacy and on my web site, I spent a lot of time yesterday afternoon looking closely at myself.

What I like most about it are things you cannot see. Although it makes me look very mature and business like, I can visualize me sitting in the cluttered basement of the photographer, listening to the hip sound track he was playing, and holding what looked like a giant pizza platter in my lap to add a bronze glow to the shadowed side of my face. In a sense, it's a piece of performance art for me: an image to try to live up to while also a reminder not to take myself overly seriously. After all, I was sitting in a cluttered basement with a pizza tray in my lap.

Oh yes, after scrutinizing 26 pictures of myself yesterday, I did something else for the first time this morning. I was looking at myself in the mirror and then without thinking, I put my hands on my cheeks and tightened the skin until my wrinkles disappeared. And for a moment I thought...—nah, I'll stay the way I am, pizza pan and all.

Certification--
I told Joe Welinsky the other day that I planned to avoid touching any "3rd rails" for a while in my candidate blogs, and here I am blogging about certification. But as Carol Barnum is fond of telling her students, "Writing is thinking." I believe blogging is a good way to sort out one's own thoughts while making yourself open to the influence of others. So here goes.

First of all, what is it?
Certification can mean a number of things. Some programs certify participants by having them go through a prescribed set of courses. PMI (Project Management Institute) is a good example of that model at the professional organization level. Others certify through regulatory examination, such as for CPAs. That model generates a lot of 3rd party training opportunities. The International Society for Performance Improvement (ISPI) certifies through inspection. Applicants submit a portfolio of artifacts and client endorsements that address specific areas of professional competency. I am familiar with that process first-hand, being a CPT (Certified Performance Technologist).

Certification differs by whom is being certified (programs or practitioners) and by who is doing the certification: commercial training organizations (such as WritersUA or HFI), academic institutions, or professional associations (Such as PMI and ISPI).

And certification can vary by professional status. Training organizations offer "certificates" to show completion of a workshop, and conferences offer "certification tracks" in specialized topics. Some academic institutions offer "certificates" as an academic credential that is bigger than a course but smaller than a diploma. Not all certifications are equal. In some cases, they warrant the recipients putting the certification as part of their professional title, as with CPA; in some cases they are cube decorations held up with push pins.

Cui bono?
As Cicero was famous for asking, "Who benefits?" A number of different stakeholders can benefit from certification programs. The most obvious in my mind is employers. Certification can be a yardstick by which to assess job applicants and by which to direct professional development among their current employees. Practitioners benefit by having an avenue for professional development that is compact and tailored toward working professionals. Professional societies benefit by having a value-add activity and revenue source. Lastly, academic institutions and training organizations can benefit by offering programs specifically aimed at certification.

So why haven't we done it?
We've been talking about certification for a long time and haven't done it as a profession. Does the fact that we haven't felt a serious enough need mean the idea lacks merit?

For one thing, the academic programs have been filling a significant portion of the need. Additionally, training vendors and conferences have also filled part of the need. And of course, the elephant in the room: the lack of an agreed-upon body of knowledge on which to base the certification criteria. (But I truly believe that elephant will be corralled in the next year or so.)

I personally think that the schools and training companies have successfully addressed entry-level certification. By that I mean that if someone were trying to get into technical communication, I would highly recommend any of the Masters or undergraduate programs I am familiar with. But what about the highly skilled and experienced professionals I work with, for example, who do not have a Masters degree? I'm not sure there is enough value in many of the programs for folks like that. Either their level is aimed at entry into the field, or their scope is too wide/too long for what many veteran practitioners need.

So what niche is not being met? I believe there could be an opportunity to certify "master technical communicators." By that I mean that STC could play a legitimate role that does not compete with its academic and vendor stakeholders by certifying when practitioners have reached a certain level of professional performance and knowledge.

Possible roles for STC in certification
STC is already in the business of peer recognition through its ranks of associate fellow and fellow. The criteria for these positions are aimed primarily at service to the profession, however, and not at performance within the professional requirements. I would recommend keeping the associate and fellow ranks exactly as they are, but we could have a certification rank, one whose criteria are based on professional achievement and standards of skills, knowledge, and performance.

We already have a method in place for handling one of the trickier aspects of that kind of certification: peer evaluation of job artifacts. We do that today through our publications competitions. We could incorporate competition achievement as part of a master technical communication certificate. Of course, that means we would have to make sure our competitions have a standard of rigor that is met, eventually requiring that certified master technical communicators be part of every chapter's competition oversight committee.

Another role for STC would be to offer training tracks and resources that could help toward advanced certification. But we need to be careful not to compete with academic programs and 3rd party training stakeholders who are doing a good job of meeting the needs of a large segment. Existing programs could be incorporated into the certification tracks where possible. Once again, however, if STC focused on master certification, I think there could be a legitimate niche there.

Comments?
These are my current, somewhat un-vetted thoughts on a topic I will probably have to deal with over the next four years if elected. Please comment freely so that I understand the multiple perspectives on this topic.

The Role of Academics in a Professional Society--
Part of my avowed platform in running for 2nd VP of STC is to help forge stronger, more collaborative relationships among the primary stakeholders of practitioners, academics, vendors, and employers within the field of technical communication. I'm starting with academics because, quite frankly, their contribution is what makes us a professional society rather than a trade association.

Academics contribute to our profession by doing the following:

• Teaching the skills and knowledge required to be a practitioner in this field
• "Keeping" the body of knowledge
• Doing research that informs best practice

Teaching
The obvious contribution that academics make is that they prepare incoming professionals in the core body of knowledge required to be a technical communicator. Additionally, they serve veteran practitioners wanting to upgrade their skills and knowledge to current practice or obtain extended skills in areas such as management.

Body of Knowledge
You want to get a roomful of academics thrashing, just say BoK. It's as much fun as watching technical writers argue about whether or not to capitalize sentence fragments in a bulleted list. I realize there is a great disparity between the gravitas of those two topics, but the principle is the same: I'm glad someone is worrying about this. The issue of the BoK for technical communication is in essence what drives an academic curriculum. Take a look at the courses that are offered in a degree program and that is a statement from that school about what it thinks the body of knowledge is. Granted, practitioners have a big stake in this discussion, but the truth is that our sisters and brothers in academia are the ones doing the heavy lifting.

Research
Ah, we get to my pet corner of the world. As George Hayhoe and I say in our book, A Research Primer for Technical Communication, "Research in technical communication is not an activity conducted in a vacuum; it is generally initiated by a problem or need to understand a phenomenon related to technical communication." As a former usability consultant, UX designer, and design team lead, I am a strong advocate for "data-driven design." Research is the cornerstone of a data-driven approach. One of the issues I see within our profession, however, is that practitioners who are living with all kinds of problems that would benefit from data collection and analysis lack the research skills to construct valid studies and draw reliable conclusions. On the other hand, academics who do have those skills, often do not have access to authentic users and artifacts with which to conduct valid research and are often time-bound within semester-sized constraints. If only they belonged to the same club, one that could put the two together in meaningful collaborations. Hey wait...!

What do you think?
I would love to see comments on this blog, especially around the following two questions:

1. What are other contributions of academics that I missed?
2. What do academics want from STC?

If given a bully pulpit...

One of my favorite topics I would like to pursue if I get elected to be an officer of STC is helping technical communication students learn how to use the tools and technologies of our industry. I have been involved in many discussions (some of them heated) over the last year or so that deal with the question, "Should academic techcom programs teach tools?" I think it is a bad question; it misdirects us and inevitably the discussion degrades into finger pointing and everyone ducking for cover.

Let's try a new question. How can the community of technical communicators help students develop tool skills while learning principles of good design? I think this new question has win/win written all over it. It falls into the "economy of abundance" arena, that is, avoid arguing over who gets what proportion of the pie (an economy of scarcity); rather, concentrate on making the pie bigger.

Students want to learn how to use the latest tools (students, heck! so do I). Vendors want to promote their products. Schools want to tout employability as an outcome of their programs. STC wants to increase membership and the value of that membership.

So imagine a scenario where a student is enrolled in an online documentation course. She is told by the professor that one of the requirements of the course is to produce a sample Help file with a specification of what that file should contain (e.g., kinds of topics, TOC, index, specific kinds of links, etc.) Just at the moment the student starts to panic, the professor points out that STC has a tools and technology section on its web site for members (and is equally available to student members). That web site has downloads of demo versions of commercial Help Authoring Tools, competency inventories (hmmm, these look a lot like the spec the professor inlcuded in the syllabus), and tutorials that focus specifically on those competencies. Wait, there's even an e-mail address for student support!

• Professor is happy: She can focus on design and critical thinking and not on clicks and drags.
• Student is happy: She has access to a tool and tutorial geared to the critical "getting started" skills a student would be interested in.
• Vendor is happy: The product is getting into the hands of future buyers and influencers.
• STC is happy: They are picking up student members with a good chance of converting them to full members after graduation. Plus, there could be some secondary revenue opportunities hidden in all of this.
  

Make that win/win/win/win.

This will be a pet project of mine if I get elected.

Campaign 2008: The Blog--
My hat is in the ring; I am running for the 2nd VP position for the Society for Technical Communication. Those familiar with professional associations know that the 2nd VP automatically becomes the 1st VP and then the president of the society. In essence, then, I am running to become president of STC in 2010. So maybe my tag line should be "The odyssey continues" (with apologies to Authur C. Clarke).

Actually, I was thinking more along the line of "Expanding our sphere of influence," to reflect how we have broadened and continue to broaden our value proposition. I know it is in vogue to talk about how technical communicators are on their way out, but I have long advocated that just the opposite is happening. We seem to be disappearing because we are redefining ourselves beyond being the mere writers of words. We scaffold the user technology experience by providing information that eases and enhances that experience. Sometimes we do that by writing helpful content, but more and more we do it in less literary ways. We are as much about content planning, architecture, delivery strategies, and management as we are about content development. And we no longer limit ourselves to describing user interfaces; we now help design those user interfaces.

And when we write, we focus our content in new directions. Our documents are no longer about products; they are about the human performance those products support. We don't just instruct patients how to take their medication, we teach them how to live with their conditions. And technology-wise, we have leapt off of the page and into Webs, Wikis, blogs, Flash demos, and knowledge bases.

Having said all that, I'm starting to like "The odyssey continues." Make the trip with me. I will be using my blog space to explore and develop my platform over the next few months. Please respond with your perspectives and to voice your visions and issues.

css: cyber sourdough--
I've been learning more about cascading style sheets the last couple of weeks than I really wanted to know. I'm only good enough to edit one, and then only with much effort. If all the .css files in the world disappeared tomorrow, I'd never be able to create one from scratch. But I get by by deconstructing, cutting, and pasting from existing ones.

So in a way, for me a cascading style sheet is like a recipe for sourdough bread. You know, where you have to start with a "seed batch" from one that was made previously. In a way, a lot of what I do with technology is like that: cutting and repurposing snippets of this and that from previous templates, web pages, spread sheets, Wikis etc. All of which represent lessons hard-learned and long-ago forgotten. I'm saved by the organic nature of technology to regrow itself from grafts and transplants.

In Dante's inner ring of hell I will be required to build a table in WikiMedia from scratch.

Know your user--
Man, I hate to rag on my own organizations, but I have had some odd user experiences with communications from organizations that are for and by technical communicators.

Two that involve STC:

• At the local STC level, I wanted to submit an application to the publications competition.
• At the society level I wanted to sign up for a webinar.

In both of these experiences, to make my final decision, I wanted one small piece of information: The price! Couldn't be found.

In another situation, I am on a volunteer committee for a technical communication advisory board, and we are to have a dinner meeting. As directions, I've been given a satellite picture with an arrow pointing at what appears to be warehouse and a description of the restaurant's ethnicity. I've requested a name and address but I'm told I can't miss it. Well, they have obviously never driven anywhere with me! If anyone can miss it, trust me, I'm your guy.

I'm sure in all these instances, the answer is "If you had only gone further in the process (i.e. try to register, or actually drive to where the satellite picture is showing you) the answer would have been obvious." My point is that I was uncomfortable going further without that information, i.e. sending in a registration not knowing how much it would be or driving through rush hour Atlanta traffic without knowing the name and address of the restaurant I was looking for.

The missing user analysis pattern here is simple, and it is one that is critical to user adoption:

1. What action am I asking the user to take?
2. What information will the user want before committing to that action?

If you're selling something, the answer to step 2 is the price.

If you're asking me to meet you for dinner, the answer is the name and address of the restaurant.

The mistake is a global one I see happening in lots of design: When they get there it will be clear.

The problem is that many will never get there because they will not try unless they get that information first.

Forget Me Not--
So what exactly does "Remember me" mean on a login screen? Obviously not what I think it does, judging by the many login screens on which I check that box and still must give my user ID and password every time. I'm hoping it means I'll get boxes of candy from them on Valentine's day.

You go, podcaster!
A shout out to STC Atlanta chapter's Michelle Schoen for making Intercom as one of the "Top Five Podcasts for Technical Communicators" (page 4 in the Sept/Oct issue).

STC Call for Papers extended
Great news for all you procrastinators. The call for papers for the STC conference in 2008 has been extended to October 19. Why present at a conference?

• It increases the odds that your management will let you go to the conference. Seriously, it takes away that doubt of "Is this just a boondoggle?" and shows that you are actively engaged in professional development.
• It helps you clarify your thoughts on a topic and increases your own learning--especially if you are reporting on something you did on the job.
• It lets you test an early assertion and get feedback on it from peers. A conference paper is a great springboard to a more robust publication.
• You get to wear a "Speaker" ribbon on your name tag. (Busted! I love getting to wear a Speaker ribbon and I save all of mine.)
• It makes our professional practice richer to hear from folks who care about technical communication.

Web cast
And speaking about the benefits of doing conferences--I just got an email from Lloyd Tucker, the director of education for STC, and he has asked me to do the presentation I did in Minneapolis as an STC web cast. Lloyd:Mike::Oprah:Dr. Phil? Who can say?

The Flip Side of Collaboration--
UX magazine had an interesting article http://www.seomoz.org/blog/how-to-ruin-a-web-design-the-design-curve about how to ruin a design that basically laments how the quality of a design deteriorates with an increase in time or number of people reviewing it. Quite frankly, it rubbed me the wrong way, but it was entertaining and is a good counterpoint to my continual championing of collaborative reviews. Actually, I'm in sympathy with the author's viewpoint, but I'm just afraid that it sets up an elitist designer's perspective that devalues the input of non-designers who might be in closer touch with the business objectives behind the design or reminders that most users of a design aren't looking for the latest in "cool." Designers left to their own devices are as dangerous as programmers or writers given the same lack of outsider oversight.

At any rate, it is an amusing and articulate read.

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.