Each week, I graphed the number of words I published, and during a weekly meeting, I held up my graph. If the number decreased for the week, I formatted the arrow red. If it increased, I formatted the arrow black.

My graphs regularly alternated between black and red arrows, and I found the whole exercise somewhat amusing and ridiculous. But I went along with it, because everyone was tracking something. We all had to create these little charts that we held up in weekly status report meetings.

Despite my cavalier attitude toward this word count tracking, I can tell you that I wrote more words than my manager could process by far. After working there several months, I had built up such a mountain of content — press releases, radio pitches, product descriptions, newsletter articles, pamphlets, e-mail campaigns — that my output was undeniable in size. I do think that holding up the silly little graphs each week had some impact on my determination to write.

Lately I have been trying to figure out the right metrics for my role as a technical writer. A lot has been written about metrics and technical communication. Many technical writers have struggled to define meaningful metrics, either because of a requirement imposed by managers or otherwise. One of the most common goals with metrics is to connect writing activities to financial figures, since this allows technical writers to establish value in a quantitative way that speaks to senior leaders.

A few possible metrics

Despite the need for these metrics, coming up with a sound way to measure the value of technical writing is a problem that remains elusive as ever. The following are several possible ways to measure the value of technical writing:

Support costs. No group has more metrics associated with it than help desks. They meticulously track the number of calls coming in, the product the call is about, and the estimated cost of each call. If a software application receives 3,000 calls a month, and each support call costs $25, the software costs the company about $75,000 a month in support costs.

How documentation affects support costs can be tricky to estimate because a lot of factors come into play:

• Support calls spike when a product is initially released.
• Support calls drop over time as users become more familiar with the application.
• Not all support calls are resolvable through help material.
• It’s hard to determine the influence of help material without a similar application that has no help material.

Helpfulness ratings. Another technique might be to embed a “Was this topic helpful?” question in your documentation. Then count the number of people who indicated that the topics helped them. You could measure your own success based on the number of yes responses versus no responses. If you equated each “yes” response with the cost of a support call, you could make a case that documentation is saving the company that amount in support costs.

For example, if 100 people indicated that topics were helpful, and half of those people might have called the support center without the help ($25 a call), that means documentation contributed about $2,500.

Unfortunately, people are always more willing to engage in feedback when it’s negative rather than positive. We love to complain more than praise, so I’m not sure how accurate this method would be.

Page hits. Page hits to help material aren’t a direct indicator of success, but what if you’re publishing web articles that double as marketing collateral? If you take the tips and how-to’s from the help, you can publish these on your corporate blog. Hits to these articles can be quantified and converted into a financial figure.

For example, let’s say you publish an article that receives 10,000 hits. Google might charge 25 cents a hit in a pay-per-click campaign to generate an equal number of hits, so the financial worth of that article you published is at least $2,500, plus the effort to write the article. If you publish 50 articles like this a year, you’re contributing a value of about $125,000.

Word count. You can also estimate the value of your contribution by measuring your word output, and then multiply this output by a cost number. For example, let’s say that in one week, you write 5,000 words. In the freelance world, a writer might charge about $75 to write 200 words. Therefore you can estimate the value of your contributions at about $1,875 dollars for the week. Of course, this method assumes that research, SME interviews, explorations of the system, and other non-writing activities are all quantified in that initial word output.

Most of these measures connect with a financial value, but if establishing financial value isn’t important, you could still measure a great many things related to your role.

What you track, you focus on

One of the problems with metrics is that we technical writers are so detail-oriented, we often get discouraged by the inability to track our contribution to the bottom line with a fair degree of accuracy. Consequently, we often don’t track anything at all — while still remaining passionate that our contributions make a significant impact.

If we dismiss metrics because they are slippery and inaccurate, we are selling ourselves short. Here’s the secret about metrics: what you track, you soon care deeply about. At work I started tracking the number of words I publish every week. As a result, I’ve noticed that I have become more focused on my output. During the day, if I haven’t published anything, I start to feel lazy and unproductive. I have to get something out there, something written and published. I also don’t let half-written things languish. I see them through to publication.

But here’s the problem in tracking word count. Most of the non-writing activities I do lose their value because I am no longer tracking those activities. This can be an important consideration when you consider that technical writers don’t actually write much of the time. I don’t know if this is a travesty of the meeting-filled corporate life, or just the nature of the job. But take a look at this graphic that Mike Landry sent me last week:

What technical writers actually do

As you can see, technical writers spend very little time writing, maybe at most 10 percent of their day. Often the more senior level you are, the less you write. This graphic accurately describes my life as a technical writer. It’s easy to let my day fill up with non-writing activities, such as the following:

• Attending scrum meetings
• Meeting with developers to talk about how an application works
• Discussing content that interns are writing
• Figuring out if I should jailbreak my iPhone to record mobile app screencasts
• Discussing IP omissions with released applications
• Talking about social media strategies we don’t have (e.g., should we engage shallowly on multiple channels, or deeply on one?)
• Working on team mission statement
• Printing out latest Intercom magazine issue on information architecture
• Figuring out how to add captions to linked images in Mediawiki
• Reviewing the latest changes to the wiki
• Gathering accomplishment highlights for previous month
• Reviewing forum posts from volunteer testers for applications in beta
• Editing existing help to include gotcha notes and known limitations clauses
• Strategizing about upcoming projects and wondering how to get funding
• Responding to various e-mail messages to clear out inbox

And before you know it, it’s 5:30 pm and the day is over without having written or produced anything substantial. However, if you have a metric you’re tracking, you suddenly become accountable. All those non-writing activities lose their value. If your goal is to publish 1,000 words a day, everything else you do is no longer the first priority. That’s what’s interesting about metrics: what you choose to track changes how you prioritize the activity. Therefore, you must think carefully about what you want to track.

The question, then, is not only what can you track, but what should you track. I am convinced that everyone should track something. Tracking can help you dramatically improve your performance in what you track. This year, in reaching to find some meaningful metric, I am currently tracking anything I can easily measure. Since I play both technical writing and marketing roles at work, I have more things available to track: words published, overall site traffic, individual article traffic, articles published, volunteer word count, RSS followers, Twitter followers, Facebook likes, Google + joins, the number of social media updates, the number of articles published, the dates for publication, and the number of volunteers who joined projects.

Of all these metrics, what is the most important to focus on? What is it that turns the wheel to make all of these numbers move forward? What is the driving force that accelerates social media growth, new visitors, and subscribers? Published content plays a huge role in driving these numbers — good quality content that aligns with our reader’s/user’s interests. The more I publish, the more each of these numbers goes up. So are words published the most important thing to track?

The consensus is against word count

Despite the grueling focus that tracking word count provides, the literature on the subject is decidedly against word count as a metric in tech comm. In fact, I have not read a single article or blog post that recommends tracking word count at all. Here’s a bit of research on the subject that I’ve culled from Intercom, Technical Communication Journal, LinkedIn, and elsewhere:

Research indicates that no industry standards are available for technical writer productivity rates. Some practices, such as page counts, have proven to be counter-productive in our experience. If a writer is evaluated by number of pages, page counts may tend to increase to the detriment of quality. In many projects, reducing page count should be the goal. Page counts also do not take into account the varying complexity levels of different deliverables; realistically, it takes longer to produce a page of highly technical material compared to user help. (“Measuring Productivity,” by Pam Swanwick and Juliet Leckenby. Intercom. September/October 2010. p. 9. URL: http://intercom.stc.org/2010/09/measuring-productivity/)

One group sees productivity metrics as dangerous. They once tracked pages per year per writer, but found the algorithm of little value. They believe that focusing their efforts on customer satisfaction is more important than counting departmental pages-per-week throughput. (“Documentation and Training Productivity Benchmarks,” by John P. “Jack” Barr and Stephanie Rosenbaum. Technical Communication Journal. Volume 50, No. 4, Nov 2003. P. 470)

The obvious, easily measured metrics are generally not very useful. For instance, there’s a temptation to measure technical writers by the gross output or superficial productivity—pages per day or topics per hour, respectively. These metrics are seductive because they are easy to calculate. But it’s an axiom of management that people will focus on whatever is measured. If you judge people by page count, they will produce lots and lots of pages. (Many of us succumbed to the “make the font bigger” approach in high school to fill out required pages for writing assignments.) If you measure writers by the number of topics they produce, you can expect to see lots and lots of tiny topics. Furthermore, this raw measurement of productivity doesn’t measure document quality. (“Managing Technical Communicators in an XML Environment,” by Sarah O’Keefe.  Scriptorium.)

At Sabre Computer Reservation Company, for example, Blackwell (1995) shows how task analysis by a team of professional writers resulted in reduction of the number of pages in one manual from 100 to 20–and the consequent savings in production costs of nearly $19,000, more than paying for the effort that went into the task analysis. Note too the importance of measuring writing productivity in units other than pages per unit of time–had such a measure been used here, writer productivity would appear to have plunged. In fact, the rest of the article makes clear, the shorter manual was a great improvement on the original, and resulted in improved customer acceptance of the product.  (“Measuring the Value added by Technical Documentation: A Review of Research and Practice.” by Jay Mead. Third Quarter 1998, Technical Communication Journal. p. 361-2.)

A question posted on Linkedin – What metrics do you use for technical writing? – had a number of responses that dismissed page count as a measure as well:

If writers are evaluated on the number of pages they produce, they’ll give you as many pages as they can churn out, not as many as the deliverable needs in order to be optimally useful to readers. Douglass H.

I would first agree that page count has no place in the discussion. There is frequently an inverse relationship between quantity and quality — at least when viewed in the context of two versions of the same document. Paul M. A.

Measuring “page-count” is ridiculous. Writers can churn out pages and pages of drivel and gobbledygook to generate “pagecount”. Editors can delete pages and pages of content to generate “pagecount”.  A better measure is the readers’ view of the documentation. Do they like it? Can they use it to solve their problems?  Dave G.

As you yourself (and several responders) have commented already, page count is a terrible way to measure productivity, especially as shorter often means better. For example, I spent several months *reducing* a user guide from 240 pages t0 80, removing the repetition and waffle… The only useful matrices for documentation are those that measure comprehension. Julian M.

Finally, perhaps nothing is as persuasive against tracking word count as this simple Dilbert cartoon.

Metrics need to measure quality

Besides the points raised earlier, measuring word count has other drawbacks. If you’re focusing only on word count, you’re not focusing on the problem. You may just be publishing more and more text, without analyzing whether the text is solving a business need or problem.

If you’re going to measure word count (quantity), you need to include some other important factors into your metrics. Jack Barr and Stephanie Rosenbaum define productivity with this equation:

(Quality X Quantity) / Time = Productivity.

(“Documentation and Training Productivity Benchmarks,” by John P. “Jack” Barr and Stephanie Rosenbaum. Volume 50, No. 4, Nov 2003. See p.471)

This is the problem with measuring only word count: without a measure of your word count against some sort of result, there’s no way to determine whether you’re being productive. You can only be productive if you make progress toward an intended result. Merely publishing more content isn’t necessarily a worthy goal in itself. The goal needs to tie to a larger objective, such as reducing support costs, increasing customer satisfaction, or improving user performance. These are all measures of quality.

To judge quality, some connection with users must be factored into a measurement; otherwise the quality measure is hollow. (Technical writers could measure the quality of each other’s work, but it’s better to have the actual user’s feedback.)  The problem is that measuring the effect on users is hard to do, so we often skip it. Instead, we make a leap to believe that publishing content will affect users in a positive way.

The widespread omission of any kind of user testing with help content has been unfortunate. In our discipline, had we been conducting user tests with our help content all along, we would have probably abandoned many unproductive forms of documentation (for example, maybe the long manual) and sought other solutions earlier (such as multimedia instruction).

Saul Carliner notes that although testing for documentation usability is important for measuring quality, “the majority of those that did said that they test less than 10% of their products” (“What Do We Manage? A Survey of the Management Portfolios of Large Technical Communication Groups.” Technical Communication Journal, 51:1. Feb 2004. p. 52).

However you do it — testing content with users in usability labs, surveying satisfaction ratings among users, or embedding surveys into help topics — it’s important to measure quality through some kind of user interaction. Did our efforts reduce support calls? Were users pleased with the help material? Did it increase usage and adoption of the application? When you can introduce a quality measurement in the metric, it makes the tracking activity meaningful.

Can we still measure word count?

I wouldn’t dismiss measuring word count altogether. Instead, I would multiply word count by the weight of the deliverable. A quick reference guide might be multiplied by 10, and a video by 20 — or something similar. It wouldn’t be hard to draw up a list of deliverables and multiply them by an appropriate weight measure to render them into output units. I mentioned quick reference guides and videos, but I could equally include other activities, such as social media updates, branding of help platforms, or formulation of strategies.

There are plenty of metrics that incorporate complicated algorithms to define a unit of work. For example, Pam Swanwick and Juliet Leckenby use the following formula:

 (# topics or pages) x (complexity of deliverable) x (% of change)

 + (% time spent on special projects)

 x (job grade)

(“Measuring Technical Writer Productivity.” Feb 2011. Writing Assist, Inc. http://www.writingassist.com/newsroom/measuring-technical-writer-productivity/)

Converting any kind of output into a unit of work helps you avoid deprioritizing every non-writing task. (On the other hand, if you want to prioritize writing so that you don’t end up like the Mike Landry graphic shows — with writing occupying just a sliver of your day — then you might consider counting words alone. It all depends on what you want to prioritize.)

Since measuring quality is integral to a metrics analysis, I plan to embed surveys into help material to gather feedback from users. Our usability group uses Loop11 to conduct regular usability tests (such as this affinity diagramming study). If I could embed this Loop11 survey into a template on the wiki, and then insert the template into specific wiki help pages, this would help me assess the quality of the content. I could also bring in people off the street, so to speak, and ask them to evaluate the help material based on a list of questions, but my preference is for real users to assess the help in an actual scenarios.

Conclusion

In most articles, metrics are used by managers to evaluate employee performance. Or they’re used by tech comm departments to justify hiring and budgets. Few approach metrics as a way for individual contributors to establish a meaningful measure for their productivity and success. Yet for me, this is perhaps the main motivation I have for tracking metrics. I know that what I track, I can improve. And this improvement can take me to the next level.

I am interested to hear what metrics you track, and the results of the metrics in your company.

Blog Sponsors

• 3Rabbitz book
• 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

Avinash says, “One of the key strategies to win at search, both organic and paid, is not playing the head game really well but playing the tail game really well.”

What he means is that the diversity of small key terms creates a long-tail effect for search engine results. The LDS Church has so much content online about a diverse number of topics, the little clicks on all those topics, though small, add up to an overpowering search engine visibility that trumps the search engine visibility that comes from the major brand words.

Avinash says understanding the long tail isn’t possible when you just look at the top 10-20 rows of your keyword metrics. For example, if you log into Omniture or Google Analytics and examine your top 20 keywords, those keywords won’t give you the full picture of what’s bringing people to your site. You need to use other visualization techniques, such as keyword tag clouds, to see the long tail.

If you view a tag cloud of the top 500 keywords on lds.org using the tagcrowd tag generator, it looks like this:

The biggest words in the tag cloud — church, gospel, family, apostles — indicate the predominance of those terms on lds.org. Analyzing the search engine metrics, you might be inclined to evaluate a site’s effectiveness in ranking for those major terms. But Avinash argues that it’s more important to look at the microwords, such as finance, friends, and modern-day, because collectively these small search words create more search engine visibility than the large ones.

It’s like the iceberg effect. Ninety percent of the iceberg is under water. You only see the top 10 percent, but this top 10 percent isn’t what is dangerous or powerful about the iceberg.

Content Strategy

The long tail has an interesting application to content strategy. Some content strategists try to ensure that the content published on their site always meets the business’s objectives and goals. You want to brand your messaging so that the target message carries through all of your content.

But according to Avinash’s argument, this kind of strategy backfires. When companies focus on saturating their content with the same brand, their search engine visibility plummets. The overall clicks are shallow. The site just ends up just targeting people already familiar with their brand.

Parallels

As I said before, diversity in keyword content has a tremendous pull on search engine visibility for a site. I don’t know if you’ve seen these, but the LDS Church has recently come out with a new strategy on mormon.org. Mormon.org is a site designed for non-LDS people interested in learning more about Mormons. The new strategy involves an “And I’m a Mormon” campaign. The idea is to smash stereotypes by exaggerating the normality and diversity of everyday Mormons. Watch a few of the videos there to see some examples. This one is one of my favorites: Hi, I’m Rochelle. Here’s one about a restaurant owner. And another about a youth worker.

None of the videos probably has any of the keywords in the tag clouds above. They aren’t really religious videos at all. The campaign is to dispel common stereotypes about Mormons by presenting real people in diverse life situations. One might say that this focus fails to achieve keyword density for the Mormon keyword brand. These profiles don’t pull any search engine clicks for words like purpose, gospel, or apostles. Instead, the keywords are more like down-syndrome, restaurant owner, and troubled youth.

It’s precisely this diversity, however, that gives appeal and search engine popularity to the videos. And it is also the keyword diversity with lds.org content that yields search engine visibility.

Blog Sponsors

• 3Rabbitz book
• 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 project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.

It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

The idea that “no one reads the manual” is certainly not new. But despite this accepted truism, most of us don’t entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.

I need this fantasy about the way my manuals are used because without it, there’s no motivation to write.

Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,

Early on in my tech writer career I had the eye-opening experience of walking into an engineer’s office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It’s like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It’s Official–Nobody Reads the Manual)

In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don’t read the manual before calling support (Gadget Problems Divide the Sexes).

It’s not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, “Your customer hates big manuals. He has shelves and boxes full of them just like you do.” (Manuals in Extreme Programming).

I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.

Joel Spolsky, a programmer and web entrepreneur, says,

Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)

When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don’t actually use help.

Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: “When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.” (If no-one reads the manual, then why bother?)

Looking at help this way is seeing the help as an emergency kit in a car. People won’t normally need the emergency kit, but when you’re stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.

Flipping Sides

Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.

No One Knows

Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it’s distributed in print, you can’t really know.

For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?

At one point, just as she and other family members were getting frustrated, one person jeered, I can’t figure it out, and there’s no manual at all!

More people get frustrated assembling things on Christmas than on any other day of the entire year. It’s a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We’re often in the same position of ignorance about our users.

If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you’re on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you’re needed.

Conclusion

As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I’m pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don’t have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.

If I find out, through feedback or on-site visits or other means, that they don’t ever read the manual, that they have never actually opened the manual beyond the table of contents, that’s okay. I hope they never have to.

Blog Sponsors

• 3Rabbitz book
• 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

Sometimes people talk about this potential move, from print to an online format, with a doom and gloom that would make you think they’re foreclosing on a house or planning a funeral for a close relative or giving up their children for adoption.

When I hear these discussions, it blows me away because I can hardly believe what I’m hearing. I admit, the look and feel of paper can provide a comfortable reading experience if you’re immersed in a 200 page novel lying on your bed on a rainy day. But the Intercom and other professional magazines or journals are not novels. With professional publications like these, the online format better matches the reading behavior of the audience. In fact, online formats provide more than a dozen advantages that print formats lack, including everything from interactivity to portability, feeds, metrics, multimedia, and more.

I’ve had some thoughts brewing all week about how people read online, not just online versus print. It’s somewhat of a collage of assertions I’m relaying here. The gist of it is that any organization or company would be crazy not to convert their paper-based magazine, journal, or newsletter into an interactive online format.

Reading Habits. When it comes to professional, job-related information, most people read on the job, during little breaks, when they’re tired of some task, or during the morning when they’re checking their e-mail and the news, or during lunch as they’re eating, or on the bus or train if they ride one. Some even read a bit in the evenings, but not as much, and rarely do they consume professional, job-related blogs on the weekends. With these reading habits, short online content that is easily accessible from a computer where most people are working better meets the reader’s needs.

Digestibility. With articles for online magazines, you can push articles out little by little, several times a week, rather than dumping 20+ articles on readers all at once and overwhelming them, as periodic print magazines do. Because you can push out articles in a more digestible rate, reader consumption of the content increases. Of course if you push out 20 articles at once through an RSS feed, the effect is the same as pushing them out all at once in print.

Portability. With online content accessible from portable mobile devices, you can read the content anywhere without forethought or preparation. For example, you can read it while you’re waiting in line, waiting for your computer to reboot, when you’re in a boring meeting, or alone in the cafeteria, or at church, or in the bathroom, or in the car while your spouse is picking up groceries. Of course you can read a print magazine in similar situations — if you’re always carrying a print magazine in your back pocket. The trouble is, opportunities for reading often sneak up on you at various times of the day. Having the content accessible at your fingertips through a BlackBerry, iPhone, or other device can mean the difference between reading and not reading.

Interactivity. With print content, you can rarely talk to the author. But with online articles, you can usually click the author’s name and find an e-mail address or contact form, or you can leave a comment below the article, or link to the author’s site (which often sends a pingback to the author’s email), and you can receive feedback from the author the next hour or day. The ability to interact with the author to share your thoughts and reactions makes reading more of a conversational, personal experience that is more engaging.

Selection. Because online forms can draw upon a global audience and stream content from hundreds of sources into a running list with thousands of titles to choose from, you’re more likely to find articles that meet your specific, niche interests. In contrast, print magazines usually have only about 10-20 articles and must keep the content at a general interest level. Because the online experience provides such a broad selection, you have greater chances of finding content that is relevant, focused, and applicable to your own interests than with print formats. I wrote about this principle previously in Damping Versus Selection.

Speed. Print magazines often require several months notice between the time you request an article, the time the author submits it, the time necessary to edit the article, lay the magazine out, proofread it, publish it, and distribute it. In contrast, online articles can omit most of these steps and publish content quickly and conveniently, even overnight. Because of this speed, online formats can tap into real-time news, stay current with the latest topics, and not worry about whether an article released months from now will still be relevant. Readers also like to know that they’re getting the absolute latest news, down to the week or even day.

Cost. Online content is usually laid out in a few standard templates with advertising in the sidebar or embedded within the article. The layout is inexpensive, and the distribution is even less expensive. Online content has almost no printing costs, and no need to outsource the content to a contract agency that creates the layout, draws dozens of accompanying illustrations, and mails the content to readers across the world. These reduced production costs generally compensate for the loss of revenue from print advertising. The result is that you can give more content away to readers for free. In this model, both the readers and publishers benefit.

Advertising Opportunities. Most advertisers don’t harness the full potential of advertising opportunities available to them in the web format. Rather than just use static images in banners and sidebars, advertisers can incorporate multimedia, including short videos, flash, audio, polls, and interactivity. Users are just a click away from entering the advertiser’s site and learning more about a product (whereas with print, users have to turn on a computer and manually type in a website). Advertisers also have an opportunity for guest posting, because space is not a limitation. If more advertisers took advantage of multimedia in the interactive web space, they would discover that online advertising can be more powerful than static print advertising.

Content Manipulation. Because online formats give you the ability to rate articles, and then sort by the most popular, or highest rated, and to automate the ratings based on page views, trackbacks, and emails, you can create compelling groupings of the most popular articles online. These lists can create more interest in the content, as they draw upon the curiosity of readers. Top 10 lists, most e-mailed articles, most clicked-on posts of the week, or lowest rated articles groupings simply aren’t possible with print.

Metrics. With print formats, you can’t rely on automated metrics tools apart from human surveys to calculate the degree to which each article is read. In contrast, online formats give you a suite of tools to track readership. Google Analytics, Woopra, Omniture, Performancing — you can use any of these tools to find detailed information about reader demographics, time per post, time on the site, most read articles, click paths, and more. Your metrics aren’t a guess.

Search Engine Optimization. With online formats, your content is findable by the whole world. People in remote countries can search and discover you. Open access and indexing of your content on Google gives you visibility, which increases your readership because it makes you discoverable. The more you search engine optimize your content, the more findable you are, which means you can actively grow your audience each day. Print formats, in contrast, aren’t easily discoverable by users unless they buy your magazine. If it’s a niche magazine, chances are it isn’t in the supermarket checkout line, so how do people find out about it? And without access to the content, how do they trust you enough to pay for a subscription?

Feed Manipulation. Most online formats have RSS feeds, which you can manipulate in interesting ways. You can create mashups of feeds that integrate multiple sources, filtering, truncating, and outputting the feed titles according to what you want to see. You can display one RSS feed on multiple sites (for example, a “What We’re Reading” type of feed from Writer River). Most importantly, readers can pull in hundreds of feeds into a single feedreader and actually stay updated with all the content (at least the content that interests them). You can’t do any feed manipulation with print formats. Nor can readers keep up with hundreds of sources. At most, you may subscribe to five or six magazines and a journal or two.

Community. Perhaps the coolest thing about online formats is the community that develops in the comments. It’s not just a one-on-one type of experience between you and the author, but rather a community of readers interacting with each other. It’s a truism that many times the comments below an article are more interesting than the article itself. Articles with a lot of comments also increase your site’s search engine visibility, drawing more readers who can find you through keyword searches. Comments are user-generated content that increases your site’s findability and value. Again, print formats lack this advantage.

Concision. Although the quality of well-researched, thought-out, and carefully structured book material is on a level above what you usually find online, I frequently find that books carry on and on about ideas they could wrap up in 20 pages. Typically, a book author must write at least 200 pages to publish a book, whether the content merits the entire length of a book or not. In contrast, online authors give you the information in short, powerful bursts. The online author gets quickly to the point, without wasting your time or padding the content with fluff to fill the pages of a book. You don’t have to slog through 35 pages before the author gets to the core of the message. For more on this, see “How the Web and Weblog Have Changing Writing.”

Niche content. In a world that is trending more and more toward specialization, we need niche content. Even in a field such as technical communication, which some might feel is already niche, really isn’t. The field has at least a dozen subfields, including information architecture, usability, content management, single sourcing, design, video, technical writing, DITA, and more. We want to learn about what we want to learn about. Online magazines and blogs provide niche content in ways that print magazines can’t. Print magazines must rely on general industry interest. According to the Long Tail, the global audience available online allows niche products to survive and even dominate mainstream products in revenue.

Completion. I recently listened to an interview with Heather Armstrong (Dooce) about her experience writing a book versus writing blog posts. She compared writing a book to pulling her brain out through the top of her skull. A book is almost never finished. It drags on for years. Books require you to structure an arc throughout hundreds of pages. In contrast, a blog post is something you can finish in an evening. You can feel completion. And you receive feedback immediately after publishing it. You get the whole writing experience in a much quicker, painless way. You don’t have to wait for years to experience it all (if what you’re working on for years even gets published). The same might be said of readers: they can completely consume your content in one sitting, rather than chipping away at it for weeks.

Shareability. Content online is immediately shareable. When you read a post you like, you can retweet it, and chances are someone else will share it, and so on until you’ve suddenly reached dozens of potential new subscribers. When content is online, readers have a quick mechanism for sharing through Twitter, blogs, email messages, Facebook, social bookmarks, or other online technologies. Because the content is more immediately shareable, you can grow your audience more quickly and increase your influence. In contrast, with print, about the only thing readers can do is cut out the article and mail it through the postal service.

Multimedia. If you look at the New York Times or the New Yorker, they incorporate a lot of multimedia into their content. The online experience isn’t just about inserting a few Youtube videos here and there. Many times you see podcasts or videos that you can subscribe to, such as discussions with the author or conversations about the latest articles. These multimedia formats provide a whole new dimension to the content. In contrast, print is one-dimensional.

Wrapping It Up

Overall, I prefer to be online is for the whole web experience. It’s not just about interactivity, immediacy, or multimedia but rather all of these components working together to provide an experience that makes that the print magazine sitting in my mailbox, or the 300 page book on my shelf, or even the newsletter PDF waiting in my inbox so much less inviting than opening up Google Reader.

If you’re interested in getting involved in a collaborating reading project, I invite you to become a link journalist on Writer River. Writer River is a social news site for sharing information about the latest news in technical communication. I’m currently revamping the site with more tools and ways to share and discover content — tools not possible in the print world. If you aren’t already registered as an author, sign up now and stay tuned for new announcements later this week.

Blog Sponsors

• 3Rabbitz book
• 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

Download MP3 (to download, right-click and select Save Target As)
Length: 35 min.

Richard Hamilton is the author of Managing Writers: A Real World Guide to Managing Technical Documentation. His book, published in 2009, is one of the few books written specifically for managers that addresses the diversity of issues that managers face today – everything from hiring and firing to motivating, metrics, outsourcing, localization, content management, and more.

Managing Writers

Richard describes the book as follows:

Managing Writers is a practical guide to managing technical documentation projects in the real world. It is informal, but concise, using examples from the author’s experience working with and managing technical writers. It looks beyond big project, big team methodologies to the issues faced by smaller, less well-funded projects.

I actually met Richard Hamilton at Doc Train West 2008. At the time, he was still writing his book, but he handed me a brochure describing the book title and its contents. I’m glad to see that some months after our conversation, he published it.

A few weeks ago, Richard sent me a review copy, so I decided to interview him for a podcast. In our conversation, we cover the following:

• Hiring and firing employees
• What to look for in resumes
• Danger points in interviews
• Motivating your team
• Rating and ranking
• Overcoming differences about tools
• Measuring success with metrics
• The importance of documentation plans
• Getting involved early in the software development process
• Ensuring proper allocation and balance across your team
• Evaluating whether writers need managers

For more information, see Richard Hamilton’s book, Managing Writers. You can also read Richard Hamilton’s blog. He has made a sample chapter available here: What Doc Managers Look for in a Resume.

Blog Sponsors

• 3Rabbitz book
• 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

For a long time, I’ve wanted to take my documentation into web 2.0 territory and enable user interaction and feedback, but I’ve been hampered by tools. Around some people, just saying the word “tool” brings up immediate negative responses. For example, when I interviewed Scott Abel about social networks and asked him about Ning, he didn’t want to discuss Ning because for him — and many others — tools are merely a selection of wrenches in a hardware store aisle. You figure out what you need first, and then you pick your tool.

I don’t think anyone who is eager to implement web 2.0 interactivity into their documentation can be so indifferent with tools. This is because there are no good web 2.0 tools for documentation. Right now everything’s a hack. You have to cobble together a solution from various things and try to make it work.

The question of tools plays an even larger part for writers who are subject to IT policies about what they can and can’t install. Even if you have free reign to use whatever authoring tool you want on your computer, many web 2.0 tools are database driven and require server components. Many infrastructure departments are particular about what you can and can’t install on their servers, assuming they give you space to install anything at all.

Last month I was dealing with these tool obstacles when a guy at a WordPress blogger dinner suggested that I work with the tools and platforms already endorsed by my company. Seems obvious, I know, but when you’re a WordPress devotee, considering any other tool for blogging seems blasphemous.

At my organization, the closest Web 2.0 tool we have is SharePoint 2007, or MOSS 2007, to be more accurate. Although SharePoint has a bad rap, the latest version is actually quite innovative, and includes blog, wiki, and RSS functionality. That said, the complexity of SharePoint’s code makes it a hard beast to tame.

I’m still in the process of testing my prototype, but I’ve learned a few things about SharePoint that may be useful to others.

With SharePoint, Blogs Make More Sense Than Wikis

The blog and wiki features in SharePoint are extremely close cousins. The source code for both a wiki page and a blog post function the same, so you can easily move your content from one format to another by copying the source code of a wiki page into the source code of a blog post. The source code consists of a lot of DIV tags referencing external styles with unrecognizable classes. And everything is unavoidably structured with inline styles.

SharePoint wikis and blogs do have some differences:

• The wiki automatically keeps revision history and shows incoming links.
• Any columns you add to your wiki appear exposed to the reader’s view.
• Wikis lack a master wiki template that you can modify to change all wiki pages.
• The blog displays the writer’s name and timestamp below the post and offers a permalink.
• The blog allows you to aggregate the posts in categories, and then see the latest posts in that category.
• The blog provides a comment field below the post, and includes a view that shows all comments.
• The blog allows you to attach a workflow to the comments field.
• Wiki pages are individual aspx pages, whereas blog posts are contained in a database somewhere.

For both blogs and wikis, the Edit button appears based on the user’s permissions for the site. In general, the blog feature is more robust than the wiki.

The Main Reason to Use the SharePoint Blog Rather Than Wiki

The main reason you might consider using SharePoint’s blog rather than wiki is for the comments feature with the blog. SharePoint’s wikis are simple to use, but they lack any kind of discussion ability. This can make collaboration intimidating. Users have to be bold enough to go behind the scenes and totally change the author’s original text.

Few actually do that. In my experience with wikis in documentation, only about 0.1% of the 3% of users who read the documentation make any edits, and the edits are either slight (such as correcting a typo) or the edit makes the documentation worse.

The comment form provides the equivalent of a discussion page for your wiki. Users are much more inclined to leave a comment.

Try as you might, it’s not possible to add the blog’s comment form below your wiki page. (A few people led me on a wild goosechase about an “Append Comments” column, but that only exists with the Issue Tracker, and it’s quirky. Actually, the blog comments feature is quirky too — just start reloading your page in Firefox when you have text in your comment form.) Some wiki “kits” that enable comments below pages are being developed, but aren’t yet released.

No Table of Contents Pane

As I was configuring my SharePoint site late one night, it dawned on me that SharePoint (and any other wiki platform) lacks the table of contents pane on the left that is so common to webhelp formats. The ability to navigate the table of contents on the left and see topics in the main content window seems critical for navigating a help system.

When I realized this, I almost stopped my entire SharePoint endeavor. But by the next morning, I started remembering the need for a communication venue and the importance of getting user feedback, so I opened SharePoint again and soon discovered something wonderful. Although users have to click the Back button to return to the table of contents, the blog feature allows you to categorize your posts (help topics) with category labels.

When you click the category, it shows you, in reverse chronological form, all the posts for that category. If you set the publish dates to the order you want, it provides a nice chapter-like feel to the online help. Readers can scan down all your help topics in a particular category. That doesn’t exist in any webhelp format I’ve seen, and for me, it’s preferable to have this larger view of all topics in the category.

Additionally, you can create mini-TOCs for each category by adding a view that shows only the post titles. Nice. It seems that for every drawback with SharePoint, there is an advantage that compensates.

Single Sourcing Printed Content

One of my biggest concerns is single sourcing the material. I pretty much settled on the fact that I’d have to do some copying and pasting and reformatting for 1-2 days to generate the long printed manual that someone would inevitably ask for. SharePoint’s blog content can’t be exported to XML or easily removed, as far as I know.

However, there may be a workaround to the single sourcing problem. Although you can’t export from a SharePoint blog to Word, you can use Word 2007 to compose your blog posts, and then publish to a Word blog. Thus, if you author your content in Word, you can then single source it to your blog. This especially works well for maintaining two image sizes.

Unfortunately, I think this method would require you to copy and paste the topic into a new Word document that you wanted to post to your blog. I haven’t explored this much yet.

You can also create a view that shows all your blog posts in one long display (not just the latest 10). If you sort it right, prioritizing the right columns, you can get it to look just like a manual. Then you can copy and paste it to Word, apply some H1 and H2 hierarchy to the headings, add cross-references, and be done soon enough.

I’m not too worried about the long printed manual because, as far as I can tell, no one has ever appreciated it when I handed him or her a 200 page manual. Invariably, anything over 50 pages gives someone a heart attack. The long manual is dead. Most users want a short guide followed by a comprehensive online resource they can search. So I’m planning to most likely maintain a 5-10 page printable guide in InDesign or Word that isn’t single sourced.

Single Sourcing Online Content

The single sourcing of online content is where SharePoint really excels. SharePoint allows you to add metadata fields to each post (these fields are called “columns”). You can then create views based on the columns — views that include pages that have certain columns, views that sort by certain columns, views that only contain pages that have certain selections in certain columns, and so on. I’ve added columns that identify different roles, and then I create the views based on those roles. It’s quite simple and powerful.

Site Metrics Advantages

SharePoint offers some other advantages that are pretty compelling. It allows you to see how many times the help site has been accessed, what topics have been viewed, the keywords users have entered in searches, and who the actual users are. This kind of knowledge is reason enough to look more seriously at SharePoint.

An Analogy of Where I’m At

Well, that’s where I’m at. It’s not the prettiest Web 2.0 documentation solution, but it’s a start. The situation reminds me of a spoon I once saw that had been sanded into a knife by an escaped prisoner. Apparently the prisoner needed a weapon, and the only thing available was a spoon, so he tried to make do with it by sanding the heck out of the sides to make it triangular.

In the end, I assume the spoon didn’t work because the police found it lying on the ground, and the prisoner was eventually caught. But it was a great attempt, and it demonstrated the resilience to improvise and adapt based on what’s currently at your disposal.

It’s an Alive Web-like Organism

Finally, I like the idea of SharePoint as a documentation tool because it’s a medium that’s alive. Most other help authoring tools are static. The Internet might as well not have been invented — it makes no difference. To me, that is the saddest thing about the tech comm. authoring tools. You author in a program on your own computer, and then upload to a file directory somewhere, and then leave the content as is until you update it again. Sorry, but that misses out on everything cool and dynamic and web 2.0 that has happened in the last 10 years.

With SharePoint, your documentation is a living entity, an organism that is constantly growing and breathing online. Like my blog — I receive comments. I look at hits. I can watch visitors in real-time. I publish comments back to it. Readership subscription grows and shrinks (but mostly grows). I see incoming links come back to it, and I link to other sites and people. As insights come to me, I add them to the blog, and other readers come and see and leave comments, and I respond. It is a living, growing, breathing body of information. Help should be the same way, not a static file that gets a push update once every 6 months.