Tag Archives: conversation

Choose Conversation and Community

We’re closing in on the second edition of my book being released and available! I’m super excited about it. I can’t stop thinking about it. On the way back from the O’Reilly Open Source Convention, I started doodling in a new notebook when all “items with an on/off switch” had to be off, and came up with this diagram for what the social web means to me.

The terms social relevance, social networking, and social media, as a triad for explaining the social web became very clear to me after reading this rather complex title: Enterprise Social Technology: Helping organizations harness the power of Social Media Social Networking Social Relevance by Scott Klososky.

Social Web

You see, these three social powers offer us content folks an entry to the strategic playing field of the social web.

What I realized is that there’s a stream of conversation and community throughout all these social threads. I hope that the second edition of my book connects these threads with more clarity than ever. I hope the long title doesn’t prevent you from tweeting about it. And I hope we all can relate our stories to each other to keep learning about the social web and growing our field’s influence on it. Let’s choose conversation and community as a strategic benefit to all our documentation efforts.

techpubs wiki

Why Wiki?

In OpenStack-land, the wiki was chosen before I got here. It has a couple of flaws for my vision for open source documentation, which became more apparent when I recently outlined my reasoning for what content goes where. By walking through the “what goes where” talk about documentation and audience, I realized something about the system we have set up (and will tweak more) and it’s this: a wiki revisions a page at a time, but our doc system with comments revisions a site at a time, namely a release at a time. It’s an important distinction to make so that you decide what a web “page” contains. It’s important to be able to articulate your needs for a web page and how it’s updated so that you can tell authors how much information you need in a page.

A page at a time is really tough for ongoing maintenance, when you don’t choose correctly the amount of information in a page. There are also difficulties with the rather immature technology in many wikis. Wikis were designed for simple editing, fast publishing. What if you have a sweeping name change? Anyone doing tech comm in a wiki knows that’s a headache for many wiki systems. What about a final spell check? Page at a time. How about search and replace? Page at a time. And let’s not talk about the times when you have to add an entire column to a table in an ASCII-based wikitext way. Your wrists will revolt, I assure you.

But an interesting expectation for a wiki that wasn’t considered when choosing the wiki is the need for comments on each page. Right now the only web systems for OpenStack that enable comments on a page are the OpenStack blog and the docs site. The docs.openstack.org site is built with DocBook XML with Disqus comments embedded on each page. It’s not quite perfect, as we’re learning as we go that not everyone wants to moderate every comment from every book on the site, and we’re still learning how to turn off hundreds of comments at a time, but it’s a great solution to a specific need. Yes, even the comment system selection needs an information architect analysis before you begin, but that’s the topic of a future post.

Ironically, our wiki doesn’t have a way to comment. So we just use it for project documentation and any comments on a project design are actually done in person at a Design Summit, which is coming up next week. Even with the great opportunity for in-person interaction at the Summit, I get the feeling there are more people wanting to “talk back” and give feedback. And certainly people want to receive feedback, to a point where they specifically bring docs to me and request publishing through the docs.openstack.org system due to the commenting system.

So what this meandering post is coming around to stating is this: You don’t need a wiki to gather feedback on your docs. Find a way to embed comments on each page and a way for collaborators to edit and you’ve got two of the basic end-goals done.

Now, make sure the end goals are known in the first place. It’s possible you need a wiki because your information would be best written a page or an article at a time. This statement is obvious when looking through your hindsight lens but difficult to be disciplined enough to state in the first place. Answer the question “why” about five levels down and it’s likely you have a solution. It may or may not be a wiki, but it’s certain that if you’re producing web content, readers have certain expectations about the content when they come to it.

Become a fan of my book!

I’ve put together a Facebook page for my book, Conversation and Community. I’ve had requests for a place for people to talk about the ideas in the book, and after talking it over with others, I settled on Facebook as a good place to bring together all the different sorts of communicators who have found my book helpful. From a pastor in Michigan to a small business on the west coat, to all the technical communicators who have found it useful, let’s gather together to socialize and talk about this shift towards enhanced social communication techniques.

Email feedback mechanisms for online help

Email has become a universal conversation mechanism for business to business notification, customer to business communication, you name it. If you’re not doing so already, you can add email links so that readers can send emailed feedback to your technical documentation team. With advanced mailto markup you can automatically enter a subject line, indicate who the email will go to, as well as enter courtesy copies and blind courtesy copies to additional people. Your inbox should not be overwhelmed with feedback emails, but a link should give customers the feeling that their comments are collected and concerns addressed. This is conversational documentation at its simplest.

If you have a large helpsite, you may want to know where the click occurred. You can use Javascript to get the URL of the page or the title of the page and automatically embed that into the email that is sent. Here is sample Javascript code to put into either the top of each HTML file or in a separate file that the HTML file refers to. You can see this code in use at docs.imis.com, thanks to Melissa Burpo‘s implementation (she adapted code from webmasterworld.com for us).

<script language=”Javascript” type=”text/javascript”>
{
//variables
var subject = “Help feedback: ” +  document.title
var bodytext = “Topic: ” + document.URL + ” – ” + document.lastModified
var pagesubject = “Link to topic: ” +  document.title
var pagebodytext = “Topic: ” + document.URL

//output an email link
document.write(‘ | <a href=\”mailto:writers@company.com?subject=’ + pagesubject + ‘&body=’ + pagebodytext + ‘\” title=\”Email this page\”>’);
document.write(‘Email us</a> |’);
}
</script>

Some of the benefits of this approach is that email is simple and universally understood by customers. An email link offers a feedback mechanism without much overhead programming or implementation. But you may need to watch out for email collection robots that take your email addresses from the mailto code and use it for spam purposes. Also, you might not get the type of feedback you want, such as people only reporting typos, rather than offering substantial additional information.

I’ve got an article that will be published on the WritersUA site soon with additional conversation and community documentation examples, but this one is a great starting point if you have your help site on the Internet but haven’t started interaction with customers at all.

Pilot or not?

While doing some research for LugIron, a startup here in Austin where I serve in an advisory role, I found a slideshow discussing signs of successful community launches by Joe Cothrel, a VP of service at Lithium.

Now, what they mean by “community” is a larger than 5,000 person audience, enterprise-type (B2B or B2C focused communities), and containing primarily forums and blogs (followed by everything else.) So, it’s not quite the same as the wiki communities that I’ve studied and participated in. But, what’s interesting to me is that one of his Warning signs on page 8 is a quote from the enterprise:

“We want to do a pilot.”

Huh? Really? Wanting to do a pilot is a warning sign of eminent failure? I guess with blogs and forums, you would want full dedication to the efforts and the goals of the community. But with wiki communities, I think a pilot is a great idea. Pilot content, pilot collaborators, pilot wiki.

What do you think? Do wikis fold up easier than forums? Are pilots getting a bad name in corporate-sponsored communities? Is this a case of the vendor wanting full dedication in their sales engagements?

Twitter and conversation analysis – who’s here?

“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. :)

Tragedy of the commons

Are professional associations going the way of bowling leagues? I don’t think so. And I certainly hope not since my employer, ASI, provides software for non-profits which includes professional associations.

But it is certainly an interesting premise that there are fewer mechanisms for casual introductions because of a shared activity like bowling or bridge. Robert Putnam wrote an article in 2000 called “Bowling Alone” that turned into this book, Bowling Alone : The Collapse and Revival of American Community. It’s a fascinating premise and I’d like to read more just based on this quote, “Our growing social-capital deficit threatens educational performance, safe neighborhoods, equitable tax collection, democratic responsiveness, everyday honesty, and even our health and happiness.”

bowlingballs

Technology – part of the solution?

If you’ve read my book, Conversation and Community, you might think I’d advocate for online activities like Scrabulous (now Lexulous) for casual introductions and getting to know people. And there are certainly stories where Twitter has introduced people to each other in new ways, such as Michael Hughes discovering common interests with others unexepctedly through Twitter and Facebook  interactions. In his post, Social Web: This old dog finally gets it, he says:

As an officer, I’ve taken quite a bit of heat over some unpopular decisions and problems lately from well-meaning and articulate critics. Twitter and Facebook have given me the opportunity to interface with some of these critics at the level of home-brewed beer and love of musical instruments.

A strong personal touch

Yet, there are some technologies that can make group work more difficult. As Clay Shirky eloquently explains in “Group as User: Flaming and the Design of Social Software,” mailing lists can have the most difficulty with signal-to-noise ratio. You know you’ve seen it happen on lists over and over again. Someone writes something that everyone needs to respond to, and then the responses don’t add to the original discussion. Even the best-behaved list members have difficulty obeying rules of conduct set forth. Naturally, the problem is more difficult when the list is large, because people who crave the “upset” attention will get more drama on a larger list.

On the other hand, blogs and wikis have built-in rules of engagement that assist with this problem. Clay Shirky outlines many assistant design decisions in the essay referenced above. But you still have to be willing to moderate comments when you are a blogger or a wiki administrator. And you have to be willing to work hard to build a community that uses the technology in a productive way.

My Book Release Party rocked!

I had such a great time at the book release party for Conversation and Community. I know I’m overdue in posting, but wanted to write something up about it. It was fun!

Party planning was fun too. To set the conversation scene, I brought these Table Topics games – the original edition and the book club edition. The cards have questions like, “what did you get into trouble for the most when you were young?” or “what alternative title would you give this book?” These were a lot of fun.

To represent “community” I brought in nearly all of my sons’ Lego figs on square Lego boards as table toppers. They were great fun! I learned later that some of the Star Wars figs are now priced at $10-12 each so some of those centerpieces were in the same range as floral arrangements, ha!

Games and LegosWe had so many people stop by and we filled the room pretty quickly. Often it felt like a reunion of the people in the book and all the writers with whom I have worked which is great fun! My parents came to the party from Dallas, then traded places with my husband so he could attend for a while too. Here’s a picture of me and my awesome husband at the party.
Anne and Paul

I signed books like crazy. I sold out of the box of books and my dad had to dig into my small stash in my car to meet demand. (Thanks Dad!) I also set aside books for people who had asked for signed copies and it’s a good thing I did!

The photographer of the Danish keyboard on the book cover, Jude Theriot, drove up from Houston and brought a signed, matted print of the photo as a gift! It was such a lovely gesture.

Announcing Conversation and Community: The Social Web for Documentation!

I’m so pleased to tell you that my book is available now from Amazon.com and BarnesandNobles.com and for sale in Austin, Texas at BookWoman on North Lamar. Published by XML Press, this book was fun to write, difficult to finish, and a dream come true for me, a kid who read 500 books in a school year in the second grade. I love books and I love this book especially. But I do want to keep improving it with blog entries here and responses to honest and thorough reviews, even negative ones.

This sample chapter is available (by direct PDF download or on Scribd) to start the conversation and I invite you to comment here or on Scribd.
Free Chapter Conversation and Community

If you’re here in Austin, I’m working on scheduling some book signings at local bookstores, and be on the lookout for an invitation to a book release party in the next few months! I want to share my excitement.

And lastly, I have to thank my blog readers – you are collectively loyal, smart, funny, and engaging. I couldn’t have written this book without you.

Twitter Guidelines from UK Government

According to this article in the Guardian, there’s a 5,000-word publication with the UK government’s guide to using Twitter. It’s available on scribd.com even, according to this Digital Engagement blog entry.

I think there are good lessons to be learned here that are relevant to any technical communicator’s use of Twitter to communicate with customers, users, or the audience we write manuals to.

At the STC Summit in May 2009, I attended Phylise Banner’s session about social media tools used in education, Learn what the Academics Already Know. Naturally, Twitter came up, and a writer who works for the CDC here in the U.S. pulled up their Twitter page. They had 9,000 followers. Yes, 9,000. My jaw dropped. Now, just two months later, they’ve passed the 10,000 follower number on the CDC_eHealth Twitter account. If sheer numbers are an indicator, these microblog posts and status updates are here to stay, and part of many communication department’s overall strategy for talking with real people.

The guidelines are summarized in the Guardian article, which I’ll excerpt here since they’re so well written.

Human: He warns that Twitter users can be hostile to the “over-use of automation” – such as RSS feeds – and to the regurgitation of press release headlines: “While corporate in message, the tone of our Twitter channel must therefore be informal spoken English, human-edited and for the most part written/paraphrased for the channel.”

Frequent: a minimum of two and maximum of 10 tweets per working day, with a minimum gap of 30 minutes between tweets to avoid flooding followers’ Twitter streams. (Not counting @replies or live coverage of a crisis/event.) Downing Street spends 20 minutes on its Twitter stream with two-three tweets a day plus a few replies, five-six tweets a day in total.

Timely: in keeping with the “zeitgeist” feel of Twitter, official tweets should be about issues of relevance today or events coming soon.

Credible: while tweets may occasionally be “fun”, their relationship to departmental objectives must be defensible.

I found all four of these guidelines matched my own experience with Twitter in the two years I’ve been using it personally. But as I look for ways to use it for my employer to connect to customers about the iMIS product and our documentation offerings, I have to pause a bit especially on the first one: Human and not over-using RSS feeds to automate tweets. I think that constant automation of tweets without an overall conversation and reaction strategy is a poor idea, but I do think that tips, release notes features like Confluence technical writer Sarah Maddox (Twitter as a medium for release notes) and others are experimenting with, have a place. I guess the key to execution here is to write microposts that sound like a real person talking about the feature and pointing to the release notes naturally. If you do decide to automate somewhat, be on the ready for replies, and ensure the timing is right and the frequency of tweets doesn’t exceed what your followers would expect.

The frequency of tweets matches the guidelines set by The Twitter Book (which I loved), at around two to four a day. In the case of people who would follow a technical writer or a software company’s account to find out tips for using the software, I would think a few tweets a week may be sufficient. I think that frequency and the timing of the Twitter posts go hand in hand. I’m contemplating Tweeting about a software release that went out a few months ago, though, so I should probably think again about that idea.

And finally, credibility is crucial for success when technical writers consider Tweeting. If the perception is that you’re tweeting in short bursts rather that delivering a technical manual or training video, well, then you’ve lost some credibility. Be sure that your goals with Twitter are in line with your goals as a technical communicator.

What do you think? Are these government guidelines transferrable to the technical communication world? Or are constituents different enough from software users that we’d better find somewhere else from which to draw guidelines?