Community purposes vary as widely as the people who comprise a community. You know that participants on Twitter Moms are not the same people as those hanging out on Dad Labs community, instinctively. But what are some of the factors that differentiate communities?

Types of communities

As I learn more about open source communities, support communities, and documentation communities, I’m finding that people who talk about community in the enterprise use categories for the types of communities that exist: business to business is B2B, business to consumer is B2C, and customer to customer (or consumer) is C2C. Besides the audience and membership targets, what are some other factors that differentiate these communities from each other?

Participation

Does 90-9-1 hold true for B2B communities? Apparently, no. The participation inequality ratios are even more, well, inequal in a B2B community. Here are notes from a Twitter chat on the socialtext.com site, as recorded by Shara Karasic @sharakarasic. “Mike Rowland doubts the community manager’s myth of 90-9-1 participation ratio. In B2B space, blog metrics have a ratio closer to 99-.9-.1. In support communities where people can ask a quick question, the 9% expands.”

Focused communities

I also heard an interview with Gartner’s Adam Sarner where he addresses the question, “What if it’s drill bits, not “cool,” products that generate lots of buzz and conversation between consumers?” I’ve often wondered as a technical writer, knowing that not many of us work on products that would generate “fan” feelings, whether “fandom” indicates whether its worthwhile to pursue community or social interaction techniques. Apparently, focused communities can generate just as much excitement and connections, whether it’s drill bits or accounting tools.

Trip-ups for communities in categories

I think one basic flaw in categorizing communities is that talking about who talks to whom makes you think of community like it’s a publishing channel, which is not a good analogy. Whether you’re publishing reviews or complaints or questions or answers, the type of community matters a lot because of the changes in audience and author. But, not all the work of a community has to do with content production, and a community is not a “channel.” Connections, building trust, communication, and maintenance of all of the system are other tasks within a community.

In summary, I appreciate the desire to strictly focus a community. I’m learning more about how those communities operate, and it looks like lots of good people are doing the same. Feel free to point to more research in the comments, and I’ll continue to share my findings.

“Hoosier,” the somewhat odd name for a native from Indiana, may have its roots in conversation. One of the stories is that when a knock from someone at the door rang out, the person inside would ask, “Who’s here?” and the greeting was shortened to “Hoosier?” Since I grew up in northern Indiana, my memories of it are fond and nostalgic. I’m particularly pleased that some of the researchers of Twitter and conversation analysis are at Indiana University, a lovely campus that I visited more than a few times.

Is Twitter appropriate for conversation and collaboration?

Tonight I’m reading a paper titled “Beyond Microblogging: Conversation and Collaboration via Twitter” originally published in the proceedings for Hawai’i International Conference on System Sciences. Written by Indiana University professor Susan Herring and doctoral candidate Courtenay Honeycutt, it describes some research questions about Twitter being used for conversation and collaboration. To quote from their discussion, “This study investigated the conversationality of Twitter, with special attention to the role played by the @ sign.”

Specifically they studied the public timeline and the use of the @ symbol that Twitter users actually invented to talk to each other as described in this New York Times article, Twitter Serves Up Ideas from its Followers. The researchers also had to filter out the other uses of the symbol, some of which are entertaining. The emoticon @_@ is one googly-eyed guy that they didn’t intend for this study. The offhand reference to someone else using the @ symbol was also filtered out, along with email addresses, and location references such as “I’m @ the coffeeshop right now.” They wanted to study one Twitter user addressing another for specific reasons.

They found that the @ sign use has doubled in two year’s time, and that Japanese and Spanish speakers use it as often as English speakers.

How is the user-invented @ convention changing conversation-based content?

They also found, and this was interesting to me, that the use of the @ symbol may actually be expanding the types of content that are being used in microblogging.

We further found that tweets with @ exhibited a
wider range of content, in comparison to tweets without
@, and that most tweets without @ just answered
the Twitter site’s question: What are you doing? This
suggests that @, in addition to directly enabling a more
interactive use of Twitter, is indirectly contributing to
expanding the types of content expressed in tweets.

In the footnotes they further note the use of the @ symbol to address others is happening in Flickr, the photo sharing site, and I would add that it’s also used often in blog comments when responding to a specific person. It’s spreading as a standard, practically! Updated to add: right after publishing this post, I hopped over to Google Wave, and in a non-profit wave I joined, they had already implemented an automatic link to a person’s Twitter account if you addressed them starting with the @ symbol. Woah.

Learning more about conversation analysis

Last month I spoke with Tanya Rabourn, who is studying information science at the University of Texas who helped me begin to understand conversation analysis. She said that studying Twitter is “sexy” right now, but also pointed out that research in conversation analysis originated with studying suicide hotlines for conversation patterns. Yow. Conversations on IRC are also studied frequently – text based conversations are easily enumerated and analyzed, I suppose. There’s even a tool available for download from Indiana University called VisualDTA that helps with Dynamic Topic Analysis (DTA) by providing a way to visualize the structure of the topic flow within a conversation. (See pages 7 and 8 of the Beyond Microblogging: Conversation and Collaboration via Twitter PDF for examples of VisualDTA diagrams.) I also learned a lot by reading a blog entry that describes written discourse at Studying online conversation in the Twitter generation that Tanya had tagged on a social bookmarking site. I learned that Conversation Analysis studies the “norms and conventions that speakers use in interaction to establish communicative understandings.”

Customer support and Twitter

Naturally, seeing how I’ve written a book with Conversation in the title, I want to relate what I’m reading to what I’ve already written. (Or is that unnatural?) So, where are the customer support conversation analyses? Has anyone studied the back-and-forth written discourse that occurs in 140-characters to see what some best practices are for engagement and troubleshooting to help someone with Twitter? Or is Twitter simply a method to get to the front of the support queue by saying “Pay attention to me because I have a smart mobile device so I must have a bit more money than your average slob of a customer!”

I believe that phone conversations for customer support have been studied quite a bit – looking for phrases that sound like triggers for anger, avoiding long pauses, and when one party overtakes a phone conversation, it’s relatively easy to detect when that’s happening. But with Twitter, you could have long pauses intentionally as asynchronous, IM-like conversations happen when someone gets up from their desk and returns after a business meeting, for example. Neither party is angry about that long pause, it’s just an understood agreement in the Twitter medium that you may or may not be immediately responsive. How does that time factor change the “agreement” for a support exchange? Is Twitter reserved for the narcissistic whiners? Or are true relationships happening and caring, meaningful attention being paid to customers on Twitter?

Wait, don’t answer these questions. I want some data and dynamic topic analysis to back up your theory.

Recently we had a few discussions on the FLOSS Manuals list about how to increase the quality of documentation for an open source project, and noted that quantity does not always increase quality. And someone noted that bad doc is worse than no doc at all! Naturally, I found parallels between the open source documentation world and the world of enterprise software.

Andy Oram started the discussion by sharing an essay positing that documentation will always be a cost, asking “Why is it more of a struggle for a project to provide information than to provide software?”  He asserts that any attempt to be comprehensive with documentation only results in overwhelming the budget, especially when video and in-person training are involved. I was reminded of Michael Hughes’ UX Matters post, Surviving Tough Times as a User Assistance Writer. He says, “We need to write less, and we need to write better stuff.”

Now, one counter question to Andy’s theory about bridging the training gap is this fact: training and education do not always come from manuals. So, in the case of an open source project’s documentation, does FLOSS Manuals align itself with the “support” mechanism of running software, or the “marketing/attention” mechanisms of getting software to be used?

In one case of a FLOSS Manuals user, Bill, he said he never can get people to read the documentation. He always ends up supporting people one-on-one with real-time communications. It sounds like Bill is the support department for his open source software project. Yet he could free up his own time by having killer doc that supports his users. I don’t think education necessarily aligns with “support,” though. Just because your users know how to use the software doesn’t mean they won’t run into the occasional bug or get stuck on a problem they can’t solve by themselves.

Here’s an example – I was talking to a guy who runs a WordPress consulting business with probably a dozen clients. He LOVES Wordpress.tv because if a client has a problem, he points them directly to a link with a video that tells them what to do to solve their problem. He’s still the central support mechanism though. The difference is that he didn’t have to create the content that helps his clients.

I think that with the introduction of community and earlier feedback in our documentation, doc becomes more “fun” and rewarding. I have much more fun writing entries for my blog than I do for the everyday doc that I write for my day job. Part of the “fun” is that the blog gives me more feedback – comments from readers, and blog stats I can see every day that show me that people really are reading what I write, plus I can see what they searched for.

What is converging is the idea that all these sources of documentation – lists, FAQs, tutorials, wikis, and so on – could live in and be maintained by one “community” or even a single hired hand. I say it in my book, and I’ll say it again, we are living in an amazing time where the audience and user is more accessible than ever through these tools that amplify conversations and connections.

I’m continuing my musings on connected conversations and tech pubs since there were such great comments and conversations going on with it.

I had an “ah ha” moment at SXSW Interactive, when one of the social media metrics panelists Rohit Bhargava said he sees three areas or channels for measurable conversations – Public Relations, Marketing (Sales), and Customer Support.

For me, those three categories crystallized this connection: where our role as tech pubs is strongest in an organization, that’s where we might start successful conversations.

Gordon McLean’s post cites Marketing and Sales as a strong tie-in, and sure, I’ve seen that and worked in that type of environment. Marketing concepts such as Business Service Management and white papers about ITIL were the primary reason and communication idea I used when I started my blog at talk.bmc in 2005. Product documentation that helps drive sales or close deals is a great method for proving our value.

Tech support seems the best alignment for many companies, as Charles Jeter’s follow-up points out. Tech publications that drive down support costs are another area where value proof lies.

Where tech writers don’t stand much of a chance, based on my limited experience, is public relations. We tend to be a fact-finding lot, not the “spin doctor” type, nor are we necessarily prepared or educated in the ways of crisis communication. I myself cringe to think of having to write blog entries for Southwest Airlines after the recent safety fine. There’s a great case study on crisis communications at BlogWrite for CEOs – Case Study: Southwest Airlines’ Corporate Blog and Crisis Communications and reading it makes me realize how difficult it can be to blog for a company as a representative of a company.

Now, my question is, will companies pay technical writers for a conversation rather than a deliverable? Perhaps only if there are some metrics to prove worth and value.

Sarah O’Keefe wrote up a nice summary of the WritersUA Pundits Panel, and Bogo Vatovec (of Bovacon)  made a statement something like this:

Introverted technical writers will not be writing help any more and will be replaced with experts moderating support forums. … Technical writers can no longer afford to hide in their cubes, they must go out and become experts and talk to the users.

I left a comment on her post that I see a similar future for our profession, although I do not have a value placed on introversion versus extroversion – likely introverts make perfectly good community managers and forum moderators since they can do that from their desks for the most part.

But, it does take some bravery to put your real personality online. I’ve found that a few of us are doing that – going from technical writer to blogger writing directly to customers.

While many of us blog to an audience of other professional writers, there are technical writers out there who are blogging to their end-user audience. Here are two examples:

• National Instruments here in Austin has a blog called “technically speaking” that they use not only to talk about their daily work but also to keep their end-users informed about documentation. For example, here’s a post about a wiki that LabVIEW users will find helpful.

• Another example is Dee Elling’s blog for CodeGear users. This entry offers a great example of a real conversation with customers. I applaud her bravery (and emailed her to tell her) in facing these sometimes abrasive responses with a sense of customer service and helpful attitude. She doesn’t always have a good message to bring (they are working furiously to give their customers more code examples which we all know is time-consuming and difficult). But she brings a message directly to customers anyway.

Is anyone else talking directly to their customer base with their blog? Consultants in technical writing and content management are definitely talking to current and potential clients – Palimpsest is Scriptorium’s blog, The Rockley Blog, The Content Wrangler, and DMN Communications to name a few. But what about conversations with end users? I’d love to see more examples.

I’ve signed up for the Give 1 Get 1 program for One Laptop Per Child, and just received the email today, November 12, 2007, with the link to the site, www.laptopgiving.org.

I read the terms and conditions with interest because I am seriously considering purchasing a laptop either for my son, who is four, or for his classroom of four-year-olds. Plus, I’ve been volunteering to help with their end-user documentation.

I’d love to buy one for every classroom at my son’s preschool but that’ll take some fundraising. I’ll boldly propose here that you can contact me if you’re interested in buying enough for a small preschool in Austin, Texas in addition to kids in least developed countries around the world.

I absolutely LOVE the spirit of the support statement. It reads as follows:

Neither OLPC Foundation nor One Laptop per Child, Inc. has service facilities, a help desk or maintenance personnel in the United States or Canada. Although we believe you will love your XO laptop, you should understand that it is not a commercially available product and, if you want help using it, you will have to seek it from friends, family, and bloggers. One goal of the G1G1 initiative is to create an informal network of XO laptop users in the developed world, who will provide feedback about the utility of the XO laptop as an educational tool for children, participate in the worldwide effort to create open-source educational applications for the XO laptop, and serve as a resource for those in the developing world who seek to optimize the value of the XO laptop as an educational tool. A fee based tech support service will be available to all who desire it. We urge participants in the G1G1 initiative to think of themselves as members of an international educational movement rather than as “customers.”

I’ve been working on documentation for the XO laptop in the wiki at wiki.laptop.org/go/Simplified_user_guide and then taking the wiki content over to an Author-it instance. I’ll write more later about a wiki-based workflow, especially with translation in mind, and we are putting a process in place. Please, feel free to edit that page or contact me if you are interested in contributing.

Personally, the most difficult part so far has been my limited ability with design and layout. I have grand visions but feel my layout skills are inadequate for a kid- and parent-friendly look within Word. Nonetheless, it is an exciting time to be a small part of such an influential project.

I’m one of the friends, family, and bloggers who is willing to help with the XO laptop. So I urge you to go to www.laptopgiving.org and put your U$399 to good use.

I want to extol the virtues of Jon Klem at Feedburner, plus give a status update for this feed and the old TalkBMC feed. Now the feeds have been combined into one, bringing subscribers over with no interruption, and Jon stuck with me for no less than a 16-email message thread so that he and I understood what was going on behind the scenes for this feed.

My goal was to have a seamless transition to my new blog, and thanks to Ynema Mangum, the talented and clever powerhouse behind talk.bmc.com and Tom Parish, the SEO brains and guru for the site, I was able to bring over the subscribers from my old feed to my new feed. So with their permission I emailed Feedburner support to explain my situation and see what the technology could do.

Feedburner has a way to transfer one feed from one account to another, and then transfer the subscribers from one feed to another. Then, the account holder (that’s me) exports the stats from the old feed to a spreadsheet for safekeeping, and then deletes the old feed and stats.

Are you as curious as I was about the most popular posts from my talk.bmc.com blog? I’m sure you’re not, but here are the top three anyway. Your analysis and interpretation is as good as mine.

1. Celebrating moms and parenthood in the workplace — TalkBMC
2. Connecting the dots, or pixels, for service impact — TalkBMC
3. Best practices in tech comm for customer feedback — TalkBMC

I’ve been doing some research for an article for the STC Intercom based on the interview I did with a friend of mine who does maintenance on the MOTO Q wiki. The article will come out this fall and I can’t wait to see if any rousing discussion appears on the STC forums. In the meantime, I want to continue to blog about wikis because I want to continue to research their use in the technical publications world.

I have had an interest in wikis for technical documentation for a couple of years now. There are a couple of good discussions on wikis for technical documentation from February 2007 on Tom Johnson’s I’d Rather Be Writing Blog as well as The Write Time blog. Tom’s post talks about using wikis to help with the documentation process. In response, there’s a wonderful entry by Lars Trieloff about exactly how a writer uses wikis for technical documentation.

While my STC Intercom article doesn’t talk about the internal wikis I’ve used for documentation tasks, as an Agile team member, I did find that the wiki housed information while development was ongoing and I also edited pages to keep them updated as I discovered something in the code that didn’t match the wiki.

It’s funny, in an early blog post I wrote on the internal blogs at BMC I said that I did not see how wikis would be used successfully for technical publications. I have since changed my once low opinion of wikis but I still see them supplementing other documentation, not substituting completely for technical documentation. I’d welcome discussion about wiki as standalone or supplemental end-user documentation. What do you think? Should the merits of wiki for certain products win out as the exact right documentation for that particular product especially one either related to an Agile methodology or social media? Or are wikis relegated to an upgrade to the customer support forum with a kludgey way of entering the information and no good method for outputting an information deliverable worth reading?

I love finding good examples of wikis, so my ears perked up when I saw the new eBay Wiki pop on my radar screen via the Read/Write Web blog. It’s part of their Community content authoring efforts and it’ll be exciting to watch it grow and mature.

The eBay Wiki is a collection of fact-based articles written and maintained by eBay Community members. You can use eBay’s Wiki to read up on topics important to you or contribute by adding topics or making existing articles better.

The information designers have done a good job of creating a navigation system with categories that are task-oriented, such as Buying, Finding, and Selling. Plus you can go into specific areas of auction interest such as antiques or baby items and so forth. To me, it’s a great example of a well-tended, easily-navigable wiki.

I’m not “into” eBay, having never bought or sold there, but I am definitely interested in their user-generated content, especially on such a large scale. Forbes.com had a catchier title for their article, and offers a more business-oriented analysis in “EBay Gets Wiki With It.” Especially interesting to me is how eBay hopes to save money with their wiki by cutting down on customer support calls. That inverse correlation is an often-used metric for proving that documentation is helping users, so I hope that they are able to track and link support cost reduction specifically to the wiki content.

For another part of an informal series about best practices in technical publications, I want to discuss customer interaction with writers and getting customer feedback about your technical documentation. How can technical writers ensure they are making the right customer connections to best help a company succeed? A few of the best practices listed in the “Tech writers as sales reps?” that the panel referred to for our Austin STC Meeting in October 2005 that are related to customer interaction are:

#7: Encourage technical writers to meet customers.
#8: Use customer advisory boards to get feedback on documentation.

Q: Customer interaction – let’s discuss the constraints on really making this happen. How have you made it happen?

A: These managers had done a lot of things to get customer feedback, from customer surveys to online feedback forms embedded in the online help. Bill Hunter guest-blogged about online feedback forms previously .

All the manager panelists liked the concept of a customer advisory board, citing that as a great best practice. Also scheduling your writers to have lunch with customers when they’re on site for training is a great idea.

One manager said from her experience that she finally understood why it wasn’t always a good idea to have writers talking directly to customers, due to the issues that a writer may not be able to resolve to the customer’s satisfaction because the politics are out of their realm of expertise or influence. Also, our curious nature might lead us to ask questions about our own tools that might not have the best answer, leading to awkward, shoe-shuffling moments. So, in this manager’s perspective, she felt that writers should not meet directly with customers unless they are trained on how to work with customers and guide discussions so that you answer questions correctly or help with things that are fixable (and realize not all perceptions can be fixed). If you’ve worked in IT for any amount of time, you know about these perceptions and what can and can’t be fixed.

Getting customer feedback can be a best practice to put into place, but you may not always get an immediate positive result. You have to ensure that your doc team can succeed by setting expectations for the requests to avoid unrealistic requests based on time or resources available. Still, any time spent with customers helps us take a walk in their shoes and should offer both participants valuable insight into the other’s position.

This post continues the series about best practices in technical communication where I blogged about:

Questioning technical publications best practices

Best practices in tech comm for fit in the organization

How to implement a document or records management system that meets ISO standards