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.