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.

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.

Breathe in, breathe out--
In my last blog I spoke about the importance of collaborative walk-throughs, and I wanted to reflect a little on what behaviors seem to make them more effective.

In a sense there are two complimentary activities that should occur in a collaborative walk-through in the early phases of a project:

• On the one hand, you want to uncover and illuminate a diversity of approaches and opinions.
• On the other hand, you want to get convergence around a set of standards and best practices for going forward.

Opposing goals? Not at all, it's more like the breathing in and breathing out that sustains life. Both are necessary. And to ride the metaphor a little longer, just as individual stress can be managed by seeking a rhythmic balance to one's breathing, collaborative stress can be managed by trying to seek a good balance between diversity-seeking and convergence-reaching.

Diversity-seeking needs to be openly valued and encouraged. Differences need to be viewed as the natural outcomes of multiple perspectives and not as competing ideas. Phrases such as "I disagree" or "You're wrong" need to be replaced with "I did it a different way," or "I see the probelm a little differently."

Convergence-reaching is the necessary coming together around an agreed upon standard or way to do something. A good exercise during a walk-though is to conduct a claims analysis on each different approach, that is, articulate the positives and negatives of an approach. And ALL approaches have positives and negatives. Concise must be balanced against incomplete, accurate against pedantic, good for novices versus inefficient for experts, etc. Bear with the following anecdote for an illustration.

The Shark
When I was ten years old, my brother and I were swimming in the surf at Gulf Shores. There are certain events in your life that cause what I call "moments of crystal clarity." A shark's dorsal fin breaking the water (when you are a swimmer) is one of those moments. Well, that happened to us and we were doing a nightmarish run through waist-high water trying to get back to shore. With safety just yards away, we were suddenly confronted by a viscious dog on the beach. To make matters worse, the dog had only three legs, thus adding credence to the bad feeling we already had about the shark. Shark behind us, dog in front of us...and then it happened, an insight of crystal clarity: We had to find the depth of water that was too shallow for the shark and too deep for the dog. We did and we walked home safely. This summarizes for me what is the essence of design, finding the right path between the shark and the dog, and claims analysis is a good way to get there.

More reflection later, the day job calls and I can see the fins and hear the snarling already :-)

Team Writing--
My current project has four writers dividing up the contents for a Help file in our belief that nine women could have a baby in one month if properly managed. Our motivation is to try to get an initial Help file delivered to QA at the same time the product first goes in for testing. Just to make it more challenging, this is the pilot project for our transition to DITA and our first release out-of-the-gate since becoming part of IBM. To heck with the proverbial adage of eating an elephant one bite at a time. For some reason I thought eating an entire herd would be the way to go. We bundled new release content, new (for us) IBM styles, new authoring tools, new publishing and deployment architecture, and a new information development methodology. Just reading that sentence back to myself has been liberating; it explains the general sense of anxiety I have been feeling and the sleepless nights of late. (It also explains my lack of blogging activity of late--I've actually been working the day job!)

Whether we survive the journey (let alone be successful) aside, I'm amazed we have gotten this far and are still alive. An important element for having gotten where we are is that we have recognized and accommodated the organic aspect of a team and the value of information in context. By that I mean that a team must learn as a team and that learning must occur wrapped around tangible examples and solutions.

We started by commandeering a small conference room and declaring it to be our project's "war room." We worked in weekly iterations, setting the goals for the next week's iteration at the end of the current week. Most importantly, we set up standing war room meetings four days a week for one hour each. In these meeting we shared tool and methodology lessons learned, white-boarded architectural issues, and discussed progress toward project goals.

When we started getting to the point where we were developing content individually, we scheduled formal walk-throughs in a larger conference room. We set up a projector and each day a different writer did a show and tell of what he or she had done. We looked at the product being documented, the Help the writer had developed, and the underlying XML structures the writer had used to identify the semantic content. We added an editor to the team at this point as well.

What I have learned most of all is that even though the daily war room meetings were absolutely necessary and were very productive, we would not have converged nearly as well without the walk-throughs. I must admit that they were stressful at times, having that many peers question almost your every decision, but that is where we became aware of the many different ways a writer could look at something and see it differently. The thrashing around in the walk-throughs is where it all got sorted out. And the range of the discussions was unbelievable, at times tackling high-level architectural issues, at others dealing with the necessary style minutia that does not become apparent until four different writers tackle what is essentially the same document. The importance of an editor at this point cannot be underestimated, acting at times as researcher and historian ("This is how we've done it in the past, this is what the IBM style guide says") and as referee at times.

Had we all hunkered down and stayed in our cubes cranking out content, our project would be a literary platypus of mismatched styles and informational structures. This was an important lesson for us because our traditional approach had been more of a writer-document specialization approach. Certainly easier to manage and maintain consistency, but one that lends itself to a waterfall convergence of documentation at the end of a project, and not as useful in an iterative, early blending of product and documentation we have been trying to get to.

In the next several blogs, I will try to capture some team dynamic guidelines I have learned through all of this.

Stay posted.

Design for the Primary User Assistance Experience--
How do you architect a Help experience? Well, the common wisdom is to design it around the user tasks. But what does that that really mean and how do you implement such a design strategy?

Let's start by asking how a user gets to a Help topic. There are four ways:

• Through a context-sensitive link on the user interface itself
• Through the Help table of contents
• Through a link from another Help topic
• Through a search/index results list

Alan Cooper, author of The Inmates Are Running the Asylum, points out that design works best when it targets a specific user. I think a similar idea for Help design is appropriate: Decide which of the four access points is your critical user experience and then optimize your design for that experience.

I think the most important user assistance experience is what happens when the user clicks the context-sensitive link. The user is on task and the Help needs to be focused and useful so that the user can get back on task as soon as possible.

The product I am working on now has page-level context-sensitive Help for every page in the application. We are designing and developing "task support clusters" around every one of those entry points. These are the critical conceptual, task, and reference topics designed specifically to support someone who has clicked on Help from a page-level Help link or button. The first topic the user gets is typically one we call a "keystone concept," a blend of what does this page do, show me an example, give me some tips--whatever seems most appropriate for someone being on that page and asking for help. Part of that keystone concept includes links to task information as well as higher level and deeper level conceptual topics. After designing and while writing the task support cluster, accommodate the other ways those topics could be accessed. Here are some implications:

• Don't put navigation and obvious UI interaction information on the keystone concept topic.
• Don't burden the users with a link farm right away that overwhelms them with new choices to make. Add value at every click; this first click should give valuable insight that the user can apply.
• Make sure that the user can link to navigational information from conceptual topics in case those topics are accessed through the TOC or other non-UI links.
• Put the appropriate task, reference, and additional conceptual links on the bottom of the keystone concept topic. When choosing how advanced or how elementary the available topics should be, assume the user was smart enough to be in the application at a fairly deep level to begin with.

The last bullet point is a key to staying parsimonious with your links. If your Help provides basic domain educational topics (for example, Firewalls 101) , collect them in their own "book" and put it in the TOC. That way, you can link to the book from a task support cluster and not provide a lot of distracting links and unnecessary navigation within the Help file for someone who is on task.

Finally, let the TOC emerge from an analysis of the content this task support approach creates.

Iterative Design and Big Boxes--
A couple of decades ago, at the early part of my technical communication career, I developed and delivered installation and maintenance training for industrial equipment (specifically, hot melt glue machinery that went on packaging lines) . Part of my job included setting up equipment for lab exercises, which required plumbing hydraulic and pneumatic lines and solenoids and such. My technical background is in electronics, so this hydraulic and pneumatic plumbing aspect was a challenge for me. Basically I had a small box of fittings and connections, and if I needed to get part A plumbed to part B, I found a fitting that went on part A and kept going into my box finding and connecting fittings until I had a jerry-rigged arrangement that ended with a fitting that matched part B. It worked.

I then had an opportunity to visit a Procter and Gamble plant in Lima, Ohio, where they were completely refitting a production line. I was thrilled; I was going to get to see how a by-gawd union pipe-fitter for a major packaging plant did it. I showed up; the union pipe fitter showed up; she had a BIG box of fittings that she kept digging into until she had an arrangement that fit on part A on one end and part B on the other. My reaction was, "Well I'll be damned!"

I moved on, away from hydraulics and pneumatics and into the more rational word of software applications. I was committed to the belief that thorough planning and design could create efficiently producible documentation that was user-friendly. Twenty years later I am a user assistance architect with a PhD working for IBM. What does that mean? I now have a BIG box of tools and patterns that I fish around in, but basically I still get from A to B by looking for what fits and doing a lot of trial and error.

But at last I think I get it: That's the way design happens!

I now give myself shorter planning windows and plan on doing frequent iterations to get it right. I fiddle less with planning tools and more with wireframing and rapid prototyping tools. My mantra is learn fast, fail early. Get something that you can play with, interact with, and show others as soon as possible.

This is not a natural behavior for technical communicators; we have this notion that things we develop should be accurate and complete (and even look good). Well, eventually, they should be, but not at first. To do collaborative, iterative design, we must create cultures where we show first drafts and half-baked ideas to others and not worry that we will be judged by their flaws and inadequacies. We must be willing to let others share their early drafts with us and not judge them for their lack of quality that can come only with polishing. There is little time for polishing at the early stage of design, and besides, you'd be polishing a lot of stuff that eventually gets thrown away.

Don't stop analyzing and planning, just recognize that the real creative breakthroughs come from building and kicking what you've built. The earlier you can do that and the more iterations you can take it through, the better the final design will be.

There's a new name on the scene that you should be looking out for (in about twenty years or so).

Ella Pari Hughes, born at 7:29 this morning, 20 inches, 6 pounds 12 ounces.

Fortunately, she gets her incredible good looks from her parents and not from her grandfather (moi).

Chinking--
I've created a new term, chinking, to mean:

• Breaking a topic into atomic chunks and then making the user get to them through individual links. Also,
• Chunking these mini-links into a page of virtually nothing but links (typically introduced with an anemic stem sentence)

Essentially, it's Information Mapping as practiced on the planet Bizzarro.

Structured writing approaches, such as Information Mapping and DITA, assert that a topic should be self contained. That means that it has to have enough depth and breadth to satisfy a reasonable need for information. Some user assistance writers take modularity to too granular a level and thus undermine the ability for a topic to stand on its own.

Chunking good.

Chinking bad.

Is It Help or Is It a Pop Quiz?--
I love the Southern expression, "Bless their hearts." It's kind-hearted, but with a tinge of self-righteous superiority. As in, "They're doing the best they can, bless their hearts." It's also sympathetic with no commitment to be helpful. As in, "Can't log into the critical network drive that has all your work stored on it? Bless your heart." I think error messages should end with it. "System 404 error, website can't be found, bless your heart."

I went into a Help file recently trying to get help about an application. I used the context-sensitive link expecting to learn more about the page I was on. I got a page with an anemic stem sentence with seven links. I wasn't quite sure which one would help me so I guessed and clicked one. It expanded into five more links. They were trying their best to help me, bless their hearts.

But my response was not one of gratitude. What I wanted to say was, "Hey, who's supposed to be asking the questions, me or you?" Since the Help screens that were being 'anything but' were part of a Help system I am working on, I get to roll up my sleeves and do something about it.

So we are now working on a new architecture, one that emphasizes giving useful information on the first click and then offering a simple, two-path fork: One that gets the user directly to the task information (procedure) and one that takes the user to a guidelines topic. Each of those topics can have more links on them (for example, extended background topics linked from the guidelines topic), but by then the users are smarter and can understand their choices better.

On simple screens, we can make either the guidelines topic or the task topic part of the initial information screen. (In those cases, if the UI is self-explanatory, consider making the guidelines topic the first topic and link to the task topic from it.) On complex, multitask screens, such as multitab screens, the Help link could open a topic that has a Tab/Description table. For each tab description, provide the double link, i.e., task or guideline.

Principles

• Don't make the users click through a link farm before they get to anything useful. Give them insight into the application at their entry point into the Help system.
• Don't overload the user with decisions at their entry point into the Help system. Expand their choices as they travel the drill-down path.

In short, the user is rarely better served by adding choices to a cognitive load that is already being taxed (they clicked on Help for a reason). Be parsimonious with links and give new information or insight at every click.

Atlanta Currents a Big Energizer for Me--
I freely admit that I went to this year's Atlanta STC Currents with low expectations. I'm not sure why. As it turned out, I left more excited and energized than from any international conference I've ever attended. The three sessions I attended demonstrated leading edge thinking that I just wasn't anticipating at a local conference (Jack Massa's report on a usability assessment project, Holly Harkness's panel discussion combining perspectives of industry practitioners and academics, and Jennifer Bowie's presentation on the declining interest in research). The keynote by the new STC Executive Director, Susan Burton, was best summarized by Dirk Bender, "There's a new sheriff in town."

What's my point? Go to your regional conferences. The class acts and presentations you get at the international conferences are speaking at the regionals. For example, George Hayhoe, editor of the STC journal Technical Communication, will be doing a presentation on Knowledge Management 101 at the Summit conference in May. George used Currents as a warm-up for that presentation.

But best of all for me was the interaction I had with other technical communicators as we talked about the "bigger issues" that face our profession and not just the daily grind of "can you get Notes working today?" It was a delightful serving of brain food and caffeine for my professional motivation.