But while short texts are met with smiles and cheers, many of my blog’s readers suggested that raising up a standard of brevity may be misguided. In fact, in many contexts, readers don’t mind long texts. What readers truly want, they explained, is simplicity, and simplicity is not always achieved through brevity.

As long as we strive for simplicity, illustrate our ideas, and focus on business relevant content, perhaps even the most technical user’s guide (such as a Network User’s Guide, shown below) might become as pleasing to read as a novel.

Is it possible for help content to be as pleasing to read as a novel?

(Drawing based on a photo of Clark Gable.)

Reading Modes

First we must distinguish between two critical modes of reading: reading to do and reading to learn. The distinction between these reading modes is an idea from Ginny Reddish (which Caroline Jarret expands on here). If you’re reading to do, you’re searching for an answer to a specific question.

Here’s an example of reading to do. You’re giving a presentation using PowerPoint, and 10 minutes before your presentation, you’re trying to figure out how to separate your slide notes from the projected slide display. In this scenario, lengthy help text is your enemy. You want the answer in as brief a space as possible, and as quickly as possible. You’re reading to do.

Ginny explains this mindset in one of her slides:

From Ginny Redish -- reading to do

(See “Understanding Web Readers (and Non-Readers) — Creating Usable and Effective Web Content.”)

I’m sure you can guess which guy in the above slide has a PowerPoint presentation in 10 minutes. But consider this other learning scenario. You know you need to improve your presentation abilities, and you’re tinkering around with Microsoft PowerPoint. There are so many buttons and features on the ribbon. It’s really overwhelming. You’re not looking to learn a specific feature, just the tool in general. You may have set aside 20 minutes a day to learn PowerPoint. In this case, you’re reading to learn.

Help content will never approach novel-like pleasure reading when a user is operating in the first mode: reading to do. But in the reading to learn mode, there is potential for something other than the frantic, frustrated help-cursing mode.

In Reading to Learn Mode, Length is Irrelevant

Let’s stay in the reading to learn mode. As long as the content is business relevant, entertaining, and simple to understand, there’s no reason to doubt the reader’s ability to become immersed in the content for long periods of time. Length becomes much less of an issue in this mode.

I don’t have hard evidence for assertions about length, but in Wired, Clive Thompson notes that the most popular blog articles are about 1,600 words per post (“Clive Thompson on How Tweets and Texts Nurture In-Depth Analysis”). This is about a seven-page essay. Writer/editor Tim Rich notes an eye-tracking study from Poynter showing that users skim until they find relevant content, and then they read for longer periods of time. Many other readers tell me they regularly consume long novels, and even wish the novels were longer.

Clearly in some contexts, length is not a problem. When content is interesting, you can have it any length you want. In one of Tim Rich’s posts, he quotes comedian Jerry Seinfield, who says, “There is no such thing as an attention span. People have infinite attention if you are entertaining them” (“Attention Spans”).

I think most will agree that text can be long and still be acceptable to readers. However, the real question is whether help content can be long and still be acceptable to readers. If not, why?

Is the Genre of Pain an Exception?

Let’s consider a basic reality. Help content is in the genre of pain. It’s right next to the tax code, your car manual, and a trip to the dentist. But does help always need to be trapped into a category of boring text no one wants to read unless they absolutely have to? Must it always be on par with a trip to the dentist?

Going along with the dentist metaphor, can the dentist ever change the experience so that you actually prefer to lengthen the visit? His fundamental activities, drilling, sticking his hand in your mouth, doing painful things to your teeth — it’s never something you want to prolong. Just like the tax instructions, no one wants the experience to be any longer, for goodness sakes. The last thing we want to do is extend the pain, right?

But Shorter Does Not Mean Less Pain

Although we do not want to prolong the pain, shorter is not always less painful. In fact, sometimes brevity increases pain. Imagine a tax booklet instruction that was just two paragraphs long. To the accountant writing the instructions, trying to keep it “as simple as possible, but not simpler,” as Einstein says, he or she may look at the concise set of instructions and feel satisfied. But this concision will likely leave me in the dark. I’ll end up scratching my head trying to understand terms, wondering if I’m interpreting it correctly, wishing there were some more examples and clarification. The time I save with shorter text is balanced by increased confusion time afterwards.

What we really want isn’t brevity. What we want is simplicity. As Whitney Quesenbery points out, “the repeated complaint about ‘too many words’ isn’t really about the word count, but about the density of the information and how this makes us feel about the information.”

When you hand users a two-page quick reference guide, their faces light up with excitement because they think the application must be simple. Project managers are cheering as well because the brief instructions seem evidence of a simple application, which means they did something right.

A sample quick reference guide. Users assume shorter means simpler, but that's not always the case.

But in reality, a two-page instructional document (such as the one on the right) for a complicated application may only leave users confused. As users make their way through the quick reference guide, they may encounter even more frustration than they would with a longer guide.

In a world of extreme concision, the novice user may be especially lost, like a hiker with a dim flashlight trying to navigate out of a rough patch of woods. The dim flashlight may be small and easy to carry, but in this situation wouldn’t the hiker prefer a larger floodlight instead?

As I said, what users really want isn’t brevity or shorter texts. They want simplicity. Who wouldn’t mind a 20 page guide if it were full of clarifying illustrations, examples, screenshots, and maybe even a glossary?

Illustrations and Simplicity

If simplicity is the goal, not brevity, you can implement a variety of techniques to simplify concepts. One of the most important strategies will be illustrations. Nothing clarifies a concept more than accompanying it with an illustration that drives the point home.

Before I push illustrations too much, let me start off with a caution raised by Tim Rich. Rich says,

There are times when a striking image expresses something in a more powerful or accurate way, but there are also countless occasions when words are an extraordinarily moving or precise media, when words can do more, say more, show more or achieve more (“On Pictures and Prose”).

In other words, images are often overrated in their ability to communicate information. A well-written paragraph full of description can sometimes communicate more information than an image. But without getting into semantic contests between text and images, I think we’ll all agree that combining the two is almost always a winning strategy. To keep the reader’s attention as you move through concepts and strategies, insert a concept diagram on every page, separating blocks of text.

A concept diagram explains a concept visually rather than merely decorating the page with a pretty picture. The concept diagram reinforces an abstract idea through visual means. Here are a few sample concept diagrams from Robert Horn’s Visual Language: Global Communication for the 21st Century (p.60).

Concept diagrams from Robert Horn's book on Visual Language

As you can see, you don’t need to be a great artist to create a concept diagram. All you need is some basic graphics abilities and an idea of how to communicate your ideas.

If illustrations are so helpful in simplifying concepts for users, why don’t more technical writers illustrate their help? Several reasons:

• Lack of graphic design skills (or feelings of inadequacy in a world of professional expectations).
• Lack of conceptual material to illustrate (it may all be procedural).
• Not enough time to create the illustrations you need.
• Difficulty in coming with a clever way to depict an abstract idea.

All of these reasons contribute to a text-heavy help. But if writers were to focus more effort on illustrating help content (and not in an Ikea-like way), you would see a complete turnaround in the reception of help content. Length would become less of an issue, and readers would welcome help content openly rather than resisting it at every level.

Screencasts

Illustrations aren’t the only solution to helping users learn a complicated process. Videos are also key. A simple screencast takes just several hours to produce. The dynamic visual interface combined with your human-narrated voice can have a powerful influence on user learning, since it allows users to see tasks in the context of an interface.

I’ve written about screencasts and voiceover techniques at length on my blog, so my purpose here isn’t to explain techniques, but merely to suggest that writers include more screencasts. Screencasts should be a more common deliverable than they currently are. Right now, based on my interactions with other professionals, I’m guessing only 1 in 10 technical writers creates screencasts, even though screencasting software applications such as Camtasia Studio or Jing are simple to learn and use.

Relevant Content

Another element required to convert help into a more pleasing reading experience is to focus on relevant content. A lot of times, we technical writers explain how to use a software application, but we leave the details of the particular business context alone. I know that when I worked as a technical writer for a financial firm, I rarely wandered into business context and use, preferring instead to merely describe how to do various functions in the application.

Why didn’t I describe more of the business use? Financial analysis is complicated, and uses are multiple. I clearly ran into the edge of my knowledge of the subject matter and didn’t feel comfortable getting into more in-depth business strategies and uses.

However, often the business context is more important than mere how-to within the interface. Many users, especially tech-savvy ones, can get the hang of an application easily enough. Look at even the simplest of apps out there — Facebook and Twitter. People aren’t clamoring for instruction on how to post updates to these web applications. Instead, users are confused about how or why they should even use the applications at all. In what contexts would they be useful or strategic? Why is it that nearly everyone has a Facebook account, but only a fraction of these people actually uses Facebook? Same with Linkedin and Twitter. The instructional material about business use and strategy is perhaps lacking (or unpersuasive).

Most help material has the same problem. The writer explains how to run a report, for example, but doesn’t say why the report might be useful, or how you might interpret the report, or who would be the most relevant audience for the report.

As another example, look at Google’s Chrome comic documentation.

Chrome's comic documentation failed for me because it lacked business relevant content.

When this first came out, it looked cool. I tore into the first few pages with a new-found enthusiasm, because this format seemed to open up documentation into a world where it was fun and fresh. But after about five pages, I lost interest, as did many other people who started reading it. It seemed to get boring and somewhat irrelevant, as well as technical, and so I clicked elsewhere. A cool idea, still, but perhaps not enough focus on business relevant content. (By the way, I have not seen Google produce any more comic documentation since then.)

There’s usually an entire dimension to help authoring that is missing from most help material: help about the business context and use. That’s the manual I would pay for, not the simple how-to about tasks already intuitive in the interface. And when you start delving into relevant business content, you have the power to keep a user’s attention at length.

Conclusion and Disclaimer

I’m not saying all help material needs illustrations, screencasts, and business relevant content, because every application or project is unique, and clearly generalizations don’t always apply. But as a guideline to follow, help could be a lot better if it more often contained these elements.

If you do include illustrations, screencasts, and business relevant content, you might not need to worry so much about brevity and word count. Your users won’t glance at a giant block of uninterrupted text and throw up their hands in exasperation. They may even start reading page after page with interest, forgetting about the time or page number.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The first step in organizing help content is to refine the existing words on the buttons, tabs, labels, and dialog boxes. When those words aren’t enough, you can supplement the interface with more text to help users achieve their goals. Some technical writers refer to this supplementary text as narrative text, others as instructional text.

I don’t have a specific methodology for reviewing interface text. I’ve reviewed hundreds of student essays in my time, and despite the rubrics that departments dream up to objectify and standardize the review, rubrics always fall short for me. They’re an afterthought to try to organize your thoughts. I typically just read through a text and have a general reaction to it. Despite my resistance against rubrics, my thoughts on reviewing interface text can be grouped into five general areas: clarity, position, brevity, convention, and informativeness.

Clarity

In looking at the words in an interface, pay attention to your gut reaction. Where does it not feel right? Are there phrases or words that jump out at you as being off? Oftentimes the interface fails to use the right word to describe an action or concept.

As I mentioned in my Technical Writer as Outsider post, determining what’s clear and what isn’t clear becomes problematic if you’re an insider to the product, having attended countless meetings discussing every aspect of the application’s terminology and design from the beginning.

Even if you’re an insider, as you look closely at the text in the application, read it carefully and analytically. Try to misinterpret it. See it as a new user might, and wipe away all your assumptions. What information is required to understand the sentences or labels? Where do you think users will become confused? Focus on these problem areas first. Replace obscurity with clarity. Switch clunkiness for plainness. Strip away fuzziness with accuracy.

In a culture of scanning and skimming, it’s easy to become desensitized to poorly constructed sentences and imprecise meaning. But when we put on our language glasses and look closely at each sentence and word to analyze its meaning within the context of the screen, we start to see the gaps more clearly. Knowledge of grammar and style is helpful in heightening awareness, but as Chris Atherton points out, even reading good writing can make your literary senses more acute. For example, after reading this psycholinguist’s essay — They get to me — about her love affair with pronouns, you’ll start looking more carefully at the words you use in your sentences.

Position

Clarity isn’t just a matter of choosing the right words. Clarity also comes from putting the right words in the right places. Proximity increases clarity. The text you add should appear next to what it describes. Mike Hughes expands on this idea and says that users are drawn to action points on a screen. He recommends putting the text just a little “downstream” of the action point. In one of the best essays on user interface text, Instructional Text in the User Interface, Hughes argues,

User assistance occurs within an action context—the user doing something with an application—and should appear in close proximity to the focus of that action—that is, the application it supports.

In other words, position your help text next to the place on the screen where the user performs the associated action the help text describes.

Hughes says users usually skip static text positioned away from points of action. Their line of focus moves straight to the actions they can do on the page. The Microsoft Developer Network also echoes Hughes’ point:

Users tend to read control labels first, especially those that appear relevant to completing the task at hand. By contrast, users tend to read static text only when they think they need to. (User Interface Text: MSDN Library)

Practically speaking, you can forget about users ever reading the static paragraph that you add below the page title. They’ll move right past it as if it wasn’t even there and instead focus on the buttons and other actions they can do on the page. Add your help text next to those action spaces.

Brevity

If there’s one undeniable principle in crafting interface text, it’s brevity. Interface text needs to be as brief as possible for two reasons: users tend to skip over large chunks of text, and the available real estate for help content on the interface is extremely limited. About all you have available is a tweet, or 140 characters. One tweet per screen, if you’re lucky. “Too much text discourages reading,” MSDN says. “The eye tends to skip right over it—ironically resulting in less communication rather than more.”

Because space is limited, you may need to provide a link to more information. A small help icon or link next to a point of confusion doesn’t tire the eye and allows you to expand on a topic without rigid space constraints. The help link can open a pop-up window in an online help or just provide a pop-up within the interface itself. The following screenshot shows how WordPress handles interface text for the Excerpt field, which appears below each post you write.

Moving text into the interface -- how WordPress handles confusing fields

Keep in mind that while your users may appreciate copious on-screen text the first time through, seeing the same abundance of text every time they perform a task on the screen can begin to clutter their view. This is one reason to use help links that open up more information: the help information only appears for those readers who need it.

Convention

Follow convention as much as possible. Your users have a history of expectations built up from thousands of hours of web browsing and application use. Users expect certain conventions that should probably be consistent in your application as well. Put the help button in the upper right. Use the standard names for buttons and labels, such as Save and Print.

One of my colleagues tells me that on one of his projects, the designer has decided to call the home button “Front” instead of “Home.” I’m not sure why. Following convention may seem a bit boring, but it decreases the learning curve for users. It’s one of the reasons Adobe tries to standardize their toolbars and interfaces across all their creative suite products — so users can carry over learning from one application to another.

When you’re stuck on names for buttons or other interface text, consult applications of a similar kind. For example, I was recently stuck on a button label in a calendar application I’m documenting. What word briefly describes the act of deleting “the current event and all subsequent events”? I checked out Google Calendar to see what term they used. While I didn’t use their exact term — “All following” — their usage helped me come up with a better solution.

Informativeness

One of the greatest challenges in editing interface text is locating all the messages tucked away in the dark corners of the application. Most often this hidden text appears as uninformative or illiterate error messages programmers have either written or ignored as they coded the application.

For understandable reasons, error messages slip by most checkpoints and make their way into production because they are hard to find. Many writers never see these messages unless they’re abusing the application. And once they appear, it’s hard to remember what you did to trigger the message. My favorite error message is “Object reference not set to an instance of the object.” This message seems to be pervasive across all .NET applications I’ve worked with. Though I’ve read and re-read this message dozens of times, I have almost no idea what it means.

How do you find all the messages in an application? How do you make sure you haven’t missed an error message, or an email notification, or an ungrammatical success message? Just because you don’t see it on the interface doesn’t mean the text isn’t there.

Sometimes programmers have a file that contains all of the language in an interface, especially if the application will be translated. Other times the messages are scattered throughout the application code. Quality assurance is no doubt aware of many of these messages, since they try to purposely break the application.

However you find the hidden text, when you do uncover one of these nuggets, they tend to provide golden opportunities for editing. I have rarely seen an error message or other notification that was informative. Usually these messages are phrased with as much obscurity and generality as possible. Programmers are sometimes careful to express in euphemisms what would otherwise be an admission of ignorance. Instead of “I don’t know why this error occurred. Sorry, maybe we’ll fix it someday,” users see “Unhandled exception has occurred in the application.”

Other times the reasons for the error are too complicated to explain in human terms. So we end up with “The conversation ended, or timed out, or resulted in a null exception.” It may be accurate, but it’s gibberish for users.

In Avoid Being Embarrassed by Your Error Messages, Caroline Jarrett recommends writing error messages in a way that tells users how to fix the problem. Piggybacking on Rhonda Bracey’s advice, Jarrett says,

… Try to give users some hint about what to do next, such as: Please try again, switch everything off and on again, jiggle the plug, uninstall the software, or whatever.

Jarrett cites an example. She says one writer changed a message from “Low Voltage Error” to “Check Power Cable.” The revised message focused on the fix rather than the problem and resulted in a “reduced support calls and certainly improved user confidence.” By focusing on the fix, you can make your interface text more informative to your users.

I’ve only scratched the surface with interface text. But if you stick with these five areas: clarity, position, brevity, convention, and informativeness, you’ll have a good starting point for improving interface text.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

(In a 2001 study) one group read (a short story) in a traditional linear-text format; they’d read a passage and click the word next to move ahead. A second group read a version in which they had to click on highlighted words in the text to move ahead. It took the hypertext readers longer to read the document, and they were seven times more likely to say they found it confusing. Another researcher, Erping Zhu, had people read a passage of digital prose but varied the number of links appearing in it. She then gave the readers a multiple-choice quiz and had them write a summary of what they had read. She found that comprehension declined as the number of links increased—whether or not people clicked on them. After all, whenever a link appears, your brain has to at least make the choice not to click, which is itself distracting. … A 2007 scholarly review of hypertext experiments concluded that jumping between digital documents impedes understanding.

In other words, the more hyperlinks that you embed within your sentences, the less readable your posts become because the brain must make a decision with each link whether to click it for more information or keep reading. After several of these links, your brain starts to take on more cognitive load. As a result, it’s easier to get sidetracked with tangents or to lose retention of the content.

Every time your readers see a hyperlink in your text, they have to pause and ask themselves whether they should click that link and follow that path, or just stay the course ahead.

For a more in-depth reading of Carr’s argument, see Carr’s article in Wired, “The Web Shatters Focus, Rewires Brains.” In that Wired article, Carr explains,

By the end of the decade, the enthusiasm [for hyperlinked text on the web] was turning to skepticism. Research was painting a fuller, very different picture of the cognitive effects of hypertext. Navigating linked documents, it turned out, entails a lot of mental calisthenics—evaluating hyperlinks, deciding whether to click, adjusting to different formats—that are extraneous to the process of reading. Because it disrupts concentration, such activity weakens comprehension. A 1989 study showed that readers tended just to click around aimlessly when reading something that included hypertext links to other selected pieces of information. A 1990 experiment revealed that some “could not remember what they had and had not read.”

To paraphrase, because of over-linked text on the web, our reading habits have become more shallow. When reading online, we skip and skim. We read a bit and click a link, and read some more and click a link. This surfing and browsing results in a shallow reading experience.

The decline in comprehension presents one of the paradoxes of the Internet: Although the Internet presents us with vast amounts of useful, enriching information, at the same time it also shortens our attention span, reduces our comprehension abilities, converts us into shallow readers, and weakens the intelligence we have cultivated.

Since the STC Summit in Dallas, I’ve had heated discussions on this site about inline links, and Whitney Quesenbery and Caroline Jarrett have tried to help me see things another way. But it wasn’t until reading Hampton’s post, which omits inline links, that I started to see the improvement in readability that results when you remove the inline links. Stripping away all those inline links really did help me focus on the content.

Though I was adamantly opposed to the denunciation of hyperlinking on the web, and I fought against the abrupt and unargued dismissal of inline links during Kathyryn Summers’ and Ginny Redish’s Summit presentations, I am now coming around to a new point of view.

My only issue is in finding the best way to correlate the endnote links with the reference points the post. It’s confusing to guess how the references match up with the sentences in the post. For example, in Hampton’s post, my video interview of Quesenbery and Jarrett is listed at the end, but I’m not mentioned by name in the post. So is the list of links at the end a bibliography of suggested reading? Am I one of the “some bloggers” reference in the penultimate paragraph? Or are the endnote links more like related posts?

It’s not that difficult to correlate the endnote links with the post content. Having taught composition in college for four years, I know how to make a general References list — you just match up the author’s last names in the References list with last names in your sentences. But I’m guessing that doing it in a consistent and detailed way will be more tedious and require more effort than most people are willing to exert. Still, I’m going to give it a try in my posts for a while.

References Cited

Carr, Nicholas. “Author Nicholas Carr: The Web Shatters Focus, Rewires Brains.” Wired. May 24, 2010.

Carr, Nicholas. The Shallows: What the Internet Is Doing to Our Brains. W.W. Norton & Co., 2010.

Hampton, Adriel. “Usability: Are Your Hyperlinks Destroying Your Readers’ Brains?“ Gov 2.0 Radio. June 16, 2010.

Quesenbery, Whitney, and Jarrett, Caroline. “Embedded Links and Online Reading Accessibility: Whitney Quesenbery and Caroline Jarrett, #stc10.” Idratherbewriting.com.  May 7, 2010.

Photo by nozoomii on Flickr.

Author Home Pages

Not cited, but useful for reading more about the authors cited in this post:

• Carr, Nicholas
• Jarrett, Carolyn
• Hampton, Adriel
• Quesenbery, Whitney
• Redish, Ginny
• Summers, Kathryn

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Forms that Work

In this podcast, Caroline Jarret talks about her new book, Forms that Work: Designing Web Forms for Usability, which she co-authored with Gerry Gaffney. Forms she discusses go beyond merely the type of IRS forms you fill out at tax time. Every website usually has some online form to collect information from users, from registration information to subscription information to purchasing information.

Caroline talks about the perceived value users must feel in order to part with their precious personal information. She explores why people dislike forms, and how companies can get around these dislikes to increase the usability of their forms, moving beyond appearance and layout and instead focusing more on relationships and conversation.

See the companion website to Forms That Work.

Buy Forms That Work: Designing web forms for usability from Amazon.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

STC Summit in Atlanta

This week I returned from the annual STC Summit in Atlanta. Every year is always a series of adventures at these conferences. I’d never been to Atlanta before. I arrived a day early, because I was originally scheduled to give a workshop on blogging, but it was canceled due to lack of participants. Attendance at the STC Summit overall was down by about 35%. I was relieved, however, at not having to put together a long workshop in addition to three conference presentations.

As soon as I got to the hotel, I ran into Alan Houser, the program chair of the conference, who asked if I wanted to eat dinner. I attribute much of my good luck in getting conference proposals carefully considered to the fact that Alan is a long-time listener of my podcasts.

The next day I decided to get some exercise. I’d been reading about a Run-n-Shoot Athletic Center, which had 10 indoor basketball gyms. The concierge confirmed the place existed, even though they never answered their phone. I took a train and then bus out into the West End to find the place. Getting outside the downtown district with all the fancy hotel and conference centers was an eye-opener, reminding me of scenes from the Bronx.

When I finally got to the address, the Run-n-Shoot center had been converted into a fitness center, the gyms converted to bowling alleys and skating rinks and playlands. The only remaining basketball court had a limited court time that ended a few hours ago.

I returned to the hotel and worked on my presentations some more. A couple of years ago, I was converted to a visual-based method of presenting. I hate extended bullets on slides, so my slides consist of nothing more than a title and an image.

To find the right images, I sometimes drag icons from Visio into Illustrator, make a few tweaks, drag them to Photoshop, make some more adjustments, flatten them, and then insert them into PowerPoint. The way I set up my blogging presentation, each slide was supposed to trigger a story, and then I had several points to cover, which I hoped to magically remember during the presentation without having a bulleted lists on the slide. This flexibility allowed me to go with the flow as I presented.

As I looked through the program, I realized that for some reason my presentation was an hour and a half instead of an hour. I only prepared for an hour and wondered when they might have told me my presentation was supposed to be 90 minutes instead of 60. They probably did tell me at some point—long ago—but my email inbox has a constant stream of messages that I often miss. I decided to splice in some tips on blog usability that I’d given in another presentation, just in case.

The Sunday before the conference begins is Leadership day. A few years ago I attended Leadership Day in Minneapolis and was excited about it, since I was a new chapter president at the time. This time around, however, I found my interest anemic almost from the start. Even with the first speaker, I surfed on my Windows mobile instead. It turns out the Society is either $500,000 or a million dollars in debt, and plans to rely partly on chapter finances to make it through. (Since our chapter seems to have an annual budget of $5 anyway, the restricted budget didn’t seem to have much impact, but quite a few people were vocal about it.)

After slipping away from Leadership Day, I returned to my hotel room to work on my presentation, to read more of Gladwell’s Outliers (which had totally hooked me on the plane), and to nap a bit.

The opening keynote by David Pogue the next morning was engaging and completely interesting—not so much because of his message, which was about the power of simplicity, but because of his theatrical, dynamic style. He knows how to deliver a keynote. I was laughing, shaking my head in agreement, twittering about it. The whole place was mesmerized. His presentation skills filled me a bit with dread towards my upcoming presentations, because I knew I couldn’t present like that.

Later that evening, I ran into Kirsty Taylor from Australia. I knew her from comments on my blog and Twitter, but she really is a fan of my wife’s blog, whataboutmomblog.com. She said she had some gifts from Australia for Jane and the kids. This amazed me—that she’d brought gifts all the way from Australia. I know I have a lot of blog readers, but my wife has blog disciples. I later interviewed Kirsty for a podcast, asking her why some blogs inspire devoted followers while others, like mine, simply invite casual attention. Not surprisingly, it’s the personal aspect of the blog, she said. Speaking to the reader’s heart and revealing appropriately, she explained.

When I presented on blogging, the session was full. I found I was able to remember most of what I planned to say, and not having bullet-by-bullet points on slides resulted in a conversation-like style, someone later told me. I breathed well and didn’t run out of content for the full hour and a half. My back started to hurt, though, from standing in the same general place so long.

I’m glad I had the opportunity to present on a topic I’m so passionate about. There are many things I’m somewhat knowledgeable about, but only a few things I’m truly passionate about. Blogging is one of them. My passion for it was apparent, and this enthusiasm made any nervousness disappear.

It seemed that after my blogging session, I ran into people I knew everywhere. Not just people who listened to the session, but people who had been following my blog, people in past chapters, past conferences, people whose blogs I followed, or people I knew from Twitter, and so on. I could hardly walk through a room without running into someone I knew, or encountering someone who knew me and wanted to say hello. My colleagues later told me that I was “amazingly social,” even though I find that comment surprising still.

After my blogging presentation ended, I started thinking about my next presentation—a 20 minute presentation about usability (“What you learn by watching others use your documentation”) in the Usability SIG progression. Usability is not my strength, but I’d given a videocast and written a post or two on the topic, which caught the attention of a SIG coordinator and he invited me to speak at a progression table.

I remembered a video I’d taken of Jane being frustrated at the computer, and I decided to use it to open up a few observations about what users do when they’re frustrated. Mainly, they don’t use help, even when they’re wringing their hands and cringing. I recommended moving the help into the interface, following some pointers Mike Hughes gave me in a podcast months before.

Progressions work differently from normal presentations. About six different presenters have round tables that seat a dozen people. Participants go from table to table, switching tables three times during the hour.

My table was next to some well-known experts in the field—Ginny Redish, Caroline Jarrett, Karen Bachman, Whitney Quesenbury, Chauncey Wilson, and Mary Deaton. Almost every one of them has either written books on usability or works as a usability consultant. When the SIG progression leader introduced me, she said, “And at the back table, we have the famous Tom Johnson …”

I thought this was funny, but it turned out to be somewhat true. It seemed that practically everyone knew me from my blog or podcasts. Even people I didn’t think knew me later added, casually during a conversation, “I feel like I’m in one of your podcasts, listening to your voice.”

My presentation wasn’t outstanding, but I don’t think it was bad either. Some said that overall the progression was the best progression they attended (I’m not sure if the same people actually came to my table). But I have to admit the progression format turns me off a little. It’s noisy. It’s weird. It’s short and seems rushed. Not many other people I met liked the progression format either.

I had one more presentation to give, this one a co-presentation with my Gryphon Mountain colleague about quick reference guides. Co-presentations, I’ve decided, are actually more difficult than single presentations, because you have to make sure the other presenter is prepared and that he or she won’t overlap topics, that your handoffs will be seamless, that you will appear as one rather than switching back and forth in awkward ways.

Also, I was a little concerned because my colleague was fairly new to presenting. He’d never presented at the Summit before, and he had a soft-spoken voice that made him hard to hear. I told him to speak up and avoid slipping into a monotone rhythm. He had a few note cards he used to remember his points on various slides, as did I.

The presentation wasn’t until late in the next day, so we still had some time. While walking about the vendor expo and meeting with people, I ran into incoming STC Toronto president Anna Parker-Richards, who I didn’t know. But as she was talking to me, I asked her about her chapter’s new meeting model, in which they charge $100 to $150 per meeting (or “event”). What she explained—the “Five and Five Model”—was so interesting I decided to record a podcast with her right there. That interview got me in the mood to record other podcasts, and soon I started carrying around my Zoom H4 recorder everywhere.

I interviewed Ginny Redish about her book Letting Go of the Words (which is really about writing web content). I interviewed Caroline Jarrett about her book on forms (Forms that Work) and why forms are important and interesting. I talked with Mike Hamilton about Madcap’s upcoming Flare-DITA solution, to Alan Porter about his book, the History of the Illustrated James Bond (and how James Bond relates perfectly to technical communicators). I talked with Sarah O’Keefe about her latest study on the state of structured authoring. I even spoke with some guy from the Netherlands and his method for prototyping with refrigerator magnets.

Tracking people down for podcasts is mostly a matter of chance. If I ever had a conversation with someone who was particularly interesting, addressing something new, such as a book or study or trend, I pulled out my recorder and asked if I could do a podcast right there. (When it comes to podcasting, I have no reservations about approaching a total stranger and interviewing him or her for a podcast. It makes the conference so much fun.)

Our quick reference guide session was scheduled for 5 p.m. on Tuesday—unfortunately at the end of the day, when everyone is tired. My colleague and I skipped some of the afternoon sessions to prepare. He practiced in the room, saying aloud his parts. On one slide I thought he had too many points for the lack of visuals, so I asked if he could make the commentary during some of the example slides. I rehearsed what I planned to say about design, but had to ultimately concede that, as much as I tried explaining it, design was like music. You could try to describe and explain how it works, but it was slippery and hard to pin down. Designs that work just feel right, regardless of any specific principles.

At five o’clock, the room was packed. No chairs were empty, people stood at the back and sides of the room, and there were even about 7 or 8 people watching from the hallway.

The lapel microphone wouldn’t stick on my colleague’s floppy shirt collar, so he held it in his hand. I buttoned up my shirt collar a notch so the lapel mic would be closer to my mouth. It worked, even if I looked nerdy. The room lacked a wireless mouse clicker, but at the last minute Jackie Damrau (who received a president’s award at the conference) retrieved one from her hotel room for us.

To start the presentation, my colleague began reading, in a funny voice, a cartoon he’d drawn. This made people laugh. Then we launched into the presentation. It went well for about the first 20 minutes, and more and more people started coming into the room. I could hardly believe how popular the session was.

Little by little, raised hands started to appear in the audience. First one hand, and then another, and another. It seemed everyone had questions to ask, which we tried to answer. Some of our answers related to slides to come, but I thought it best to give the answer now, with full elaboration, rather than wait. I think that proved to be a bit of mistake, because too many questions can kill the flow and rhythm of a presentation. For everyone that asks a question, there’s another person that doesn’t want to listen to someone asking a question.

Still, the majority of people remained engaged and interested in what we had to say. The quick reference guide examples provided visual appeal and were practical. My colleague projected well and covered good ground. More than a dozen attendees stayed after to talk to us individually, and for the next day people complimented us on the presentation.

But later in the evening, when we returned to our hotel room and checked the STC 09 Twitter feed, a tweet did provide a bit of a downer, because the person said we needed a moderator, more concrete examples, and that we were more frustrating than interesting. Negative feedback is sometimes hard to take, but it is more instructive in the long run, and I could see how to improve our delivery the next time.

That night, even with the sour tweet, having completed all my presentations, I felt a burden lifted from me. At the same time I wanted to collapse from exhaustion. I went to dinner with my colleagues and a few new friends. I thought a woman who joined us (Trina) had a foreign accent, but she turned out to just be from Milwaukee. Another LDS technical writer from Connecticut (Chris Keeling) joined us. A former drill sergeant and game aficionado, he had a love for his old blind and deaf cat, which he gave an IV to every day, he explained. The cat also drooled on his head in the morning. He and another woman, coincidentally, were both former military intelligence officers who translated Russian, or something.

As the night ticked away, I couldn’t help but feel satisfied both emotionally now that the presentations were over and physically now that I was eating.

After the final conference luncheon the next day, I still had a few more hours to kill. I had a goal to interview ten people for podcasts, and given my theme of recently published books, Karen Bachman recommended I talk with John Hedtke, who has published 26 books, his most recent one on Disaster Preparedness.

This was my first encounter with John. He was articulate and well-spoken. He explained why he wrote about disaster preparedness—”for the money,” he said. I prodded him a little more. Perhaps you had a disaster in your own life that motivated you to explore this topic? I asked. No, he said. I really just wrote it for the money.

While I was talking with him, though, he mentioned that he wrote in the evenings and weekends, after work. You mean you have a regular day job besides your book writing projects? I asked.

Apparently, yes. Computer books (most of what he’s written) have a short shelf-life, he explained. And most nonfiction books don’t make back their advance checks, which are usually between six to ten thousand dollars. Listening to John made me think twice about book publishing.

Regardless of whether I ever write a book, I reflected on the idea for a while in a dreamy way—thinking about possibilities and topics and who might publish it and whether it would be in color or not. Shortly after my conversation with John, I flew home.

Overall, the Summit is always a good experience because it gets me engaged in the profession. It engages me with presentations, which requires my best thinking, organizing, and delivery skills. It engages me with podcasts, interviewing people on the spot, drilling deeper into their knowledge. It engages me with new ideas through sessions from experts and authorities in the field. And it engages me with a new environment, surrounding me with new friends and a new city. It is a short stretch of time, about four or five days, but its effects last throughout the year.

By the way, this year all presentations (except the progressions) were recorded. You can buy the presentations from the STC (called Summit@aClick) for a price (no one knows how much yet). I’m told that I can also post my own presentations on my blog for free, which I’ll certainly do when they’re available.

If you enjoyed this writeup, see my write-ups from previous conferences:

• Technical Writer as Conversation Stopper, and Other Notes from the STC Summit in Philadelphia
• Podcasting at the STC Conference: Reasons, Methods, and Reflections
• Post Doc-Train Thoughts While Sitting in the Airport in vancouver

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree