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

• 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

• 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

• 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

• 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.