I’m late to write up my thoughts on Gordon Mclean’s post, Strange Bias, but I give him a belated thumbs up for great self-inspection and data query in the post.

My take? I read ““Why James Chartrand Wears Women’s Underpants” on Copyblogger in December. It’s a great survivor story that you should read in its entirety, but the gist of it is that James is a pen name for a woman freelance writer, who writes the popular blog Men with Pens. Merely representing herself as a man made a real difference in her career trajectory. I was shocked, though, that she never had to talk to clients on the phone and that she never went to conferences or spoke at conferences.

It made me wonder if I’d have 10 times the subscribers to my blog if I had started in 2005 as Tom Gentle. It really did. But we are who we are, and being genuine and transparent is all part of my blogging experience. Many of the opportunities I’ve had in the past 4-5 years are somehow related to my blog and the work ethic it requires to maintain.

And to answer Gordon’s question, “is it just me?” I’d say, my experience with tech pub teams I’ve been on are that men are the slightly minority gender. If you believe Quantcast web stats about the STC website, you see that 61% of site visitors are female. I’ve also observed more women at tech comm conferences than men.

But, socializing being, well, social, means you tend to relate to people like yourself, right? So followers, friends, and fans, being self-selecting as they are, may prove that men follow men and women follow women. I think Twitter certainly reflects this tendency, since research shows men follow men on Twitter. And bloggers use Twitter far more than the general population (See the pie chart on the Day 5 report).

If you read Technorati’s State of the Blogosphere you see that 2/3 rds of all bloggers are men. So the 55% blogs written by men that Gordon reads actually differs from the predictive 66% overall population. A great observation, Gordon, well done.

I’ve published a long-ish article on the WritersUA site where I describe techniques for user assistance that let the user participate. It starts with simple techniques such as comments and moves towards community documentation efforts. Please read and share Putting the User in User Assistance. I’d love to hear what you think about these techniques.

One of my readers asked for a post about cloud computing. I went straight to my in-Austin expert, Ynema Mangum, and she exceeded my expectations by writing the post! This is a guest post by Ynema Mangum, architect at Hewlett-Packard. She contributed information about web metrics to my book, Conversation and Community: The Social Web for Documentation. She’s working on a chapter for the upcoming book Cloud Computing: Principles and Paradigms. I’ll post a second guest post from Ynema next week.

Cloud computing represents a paradigm shift from traditional IT rooted in heavy process and technology-centric management to agile processes and service-centric management. This shift converges with Web 2.0 and distributed application design, resulting in democratized computing and an economic revolution — where the developer can deploy enterprise grade applications and user services without having to pay the capital expense for the underlying IT infrastructure. It represents a radical change and requires a culture shift for IT when building a private cloud.

Today, confusion exists about exactly what cloud is as well as how it compares to current IT methods and technologies. Clearing the air is the first order of business.

Public Cloud vs. Private Cloud

The public cloud model has is vastly different from the private cloud, creating a chasm in their connection. The current expectation for public cloud infrastructure and platform services is the ability to provision compute, storage, database and networking resources in a few minutes, completely online without establishing an agreement or talking to a person.

Private cloud computing has different challenges for the service provider, but often is faced with the same expectations. Regulatory compliance, security, and privacy are just the icing on the cake. The concern that seems most often forgotten in comparing public and private cloud models is quality and compliance of data.

Public cloud providers, in general, do not care what type of application or data you throw on the cloud. Compare that with an enterprise private cloud, where IT not only owns the performance and availability of the organizational assets, but also has responsibility for ensuring that business assets are used in the proper manner. Applications that are developed and deployed on a private cloud need to go through a series of quick checks before they can be cleared in order to prevent misuse of company assets or the risk of retrofit and ground-up redesign of applications developed outside of IT.

There is an ongoing challenge in enterprises today to segment cloud service offerings, architectures and buyer types into useful, focused categories for strategic planning, according to Frank Gillett of Forrester. For public cloud service providers, two IaaS market categories have emerged, the software Platform as a Service (PaaS) and virtual Infrastructure as a Service (IaaS) offerings that differ by level of infrastructure service and abstraction offered.

For private clouds, there are two types of compute clouds, server clouds and scale-out clouds.

• Server clouds are built for the traditional needs of the business applications, catalyzed by x86 server virtualization and adding self service provisioning.
• Scale-out clouds are designed for massive, highly distributed applications.

Virtualization vs. Cloud

Virtualization and cloud computing have much in common, including phrase overuse and hype, resulting in a lack of understanding of both. Cloud computing does not equal virtualization, but does use abstraction as a common element in each layer of the cloud. In fact, the most distinct differences between the two terms seem to be in the areas of abstraction and IT maturity.

Virtualization is datacenter-centric and technology-centric, while cloud computing is service and user-centric. Memory, desktops, applications, storage, applications, platforms, and servers can be virtualized, or abstracted from the underlying technology. Cloud computing can use or not use virtualization in its architecture.

Typically, the virtualization referred to for use in cloud computing is operating-system virtualization, where multiple virtualized machines can run on a physical server, secure and isolated from one another. These VMs provide benefits in that they can be provisioned without requesting physical hardware, changed, moved, controlled, terminated, and configured more easily than a physical machine. This results in greater efficiencies and productivity in IT, and also increases agility for the services developed and deployed on these VMs.

Beyond this layer of virtualization, cloud computing adds platforms, agile processes, and services for developers, providing value far beyond virtualization.

Utility Computing vs. Cloud

Utility computing is a business or economic model, whereas cloud computing is about technology and process architecture. Utility computing allows users to receive computing resources and “pay by consumption”. Cloud computing is a much broader concept, taking into consideration the underlying architecture and actual services delivered.

Consumer users have been reaping the benefits of the utility model in cloud computing for years — at the application as a service level. It is developers and IT who are using cloud computing in a transformative way now. IaaS and PaaS allows them to develop, test, deploy and run apps that can scale on enterprise grade technology, all without having to pay the capital expense for the underlying infrastructure. This is creating a new cloud economy and truly represents the democratization of computing.

Boy, it must be getting harder and harder to be a web writer. I’m reading Content Strategy for the Web, and the web writer job description is intimidating! The quote that stuck with me talks about the Web Writers Real Job: problem solvers who write well. I do hope this quote describes many technical communicators today.

“The web writer’s mission? Useful, usable content that’s also enjoyable. It’s her job to begin a conversation with the reader that results in mutually beneficial outcomes all around. A problem solved. An article found. A connection made.”

All of these outcomes can be tied to thinking about technical documentation as a conversation starter. My book talks about social media enabling those conversations. Often, though, social distribution is simply the technique, but the web itself is the medium. When writing in that medium, we must be the best writers with the most considerations taken into account while writing. Search engine optimization. Style and voice when writing for the web versus print. Information architecture, organization, and label naming. Maintaining a content inventory. Auditing and editing content. Testing content. Handling workflow, reviews, and deadlines. The list could go on and on.

And here’s the thing. People are not backing down from figuring out a great web strategy despite the challenges, and finding great success. I had a great lunchtime conversation with Brian Massey, the Conversion Scientist. He basically mapped technical publications’ typical goals to the personas that help you encourage a conversion. Fascinating! He describes four personas typically used by marketing writers on the web in the blog post, Relate to Four, Connect with Thousands:

Methodical - Probably the first persona to come to mind when talking about traditional technical documentation, perhaps not even all that web-hungry. They want proof, answers, solutions, in an orderly fashion. They’d probably download and read a PDF file if it’s offered.

Competitive - They want information that will make them better, smarter, or cutting-edge. They may be the implementer at a company who will train others in the product you’re documenting, so they’d want scenarios that make them look good.

Humanist - To me, this type of persona, one who looks for relationships and the human element, might be difficult to deliver technical documentation to. They might pick up the phone to call tech support faster than looking up a question online, unless a community is behind the documentation that they can relate to. The humanist may also appreciate case studies that help them relate to a real story.

Spontaneous - They want to know the answer quickly and move on, so scannable headlines and topic authoring with any topic being a potential entry point will probably work well for them.

I’m definitely looking at my web writing in new ways. Not just in terms of deliverables, but also in terms of the content I can deliver to the right audiences, to help them meet their goals.

I don’t know if it’ll sound like a whisper, but I am excited that my proposal was accepted for the 2010 STC Summit in Dallas! Here’s what I’ll be presenting:

I’m participating in a Content Strategy Progression as described on the STC Content Strategy Special Interest Group blog entry on said progression. I’ll talk about content that is “Shareable, Searchable, Sociable, and Don’t Forget Syndicated.” That should be a fun session, and I’m just sad I won’t be able to wander around the room myself and soak in the Content Strategy goodness!

My proposal for a presentation titled, “Strategies for the Social Web for Documentation” was accepted, hurrah. Here’s what I have as learning objectives for the session, but I’d love to hear your questions as well before I prepare all the slidedeck. What would you want to learn?

Session Objectives:

1. Identify specific types of tools on the social web, such as tags, blogs, and wikis
2. List risk areas and pitfalls
3. Identify writers’ roles with social media (instigator or enabler)
4. Plan a strategy of listening, participating, building and then offering a platform or community

Session Description:
Let’s say that the most driven and driving developer on your team, who also happens to be a popular blogger, comes to you and asks why your end-user documentation doesn’t allow comments or ratings. Rather than stammering something about Wikipedia’s latest scandal, or reaching for imperfect responses that sound like lame excuses, do your homework and learn best practices from others who are implementing social web content that is conversational or based on community goals. Along the way you may realize there are good reasons not to implement a social media strategy, based on studying the potential community and time you’d spend in arbitration with community members on contentious issues, or you may discover that you can borrow from benefits of a single approach while still meeting business goals.

(Kudos if you recognize the song lyrics to which the title and lead refer.)

I loved the line, as delivered by Tom Hanks in A League of Their Own, “There’s no crying in baseball!” I know there are times when the crying must happen without delay. I don’t believe most workplaces actively encourage crying – at least not outside of acting careers.

When I’ve read Agile practitioner reports that tell tales of times when technical writers have left meetings and fled to cry, I am not just surprised but a little dismayed.In A Tale of Two Writing Teams from an Agile conference three years ago, one anonymous writing team reported one writer in particular crying during the daily standup and in retrospectives.

As the prioritization changed from the new Java web program (the new and fun stuff) to updating the old, stuffy legacy client server code, writers’ tasks switched from creating new online Help to updating old versions of end-user documentation (books). This change caused the writing team to revert to form—that is, they began to demand written design specs. It’s as if once the technology took a step back from online Help to written documentation because of the prioritization of the product backlog, so did the methodology choice. I tried my best to coach the writers to work creatively with developers on the old stuff as they had on the new, but there was an insistence that the existing specs
for the old legacy code would now become outdated, and the writers were completely uncomfortable with that. One writer—the one with the most tenure—
moved out of the team room, citing lack of privacy and her ability to contribute as the reasons (when I know that it was really a lack of embracing the change). I can remember several episodes of her crying during daily scrum meetings and in
retrospectives.

The paper author’s analysis indicates that the stress of embracing change caused the outburst I think the stress of change can bring on an emotional outburst, and sometimes people have crying as their stress release.

But what is more interesting to me as a content provider is that the change in the tools used to deliver the documentation seemed to correlate to the writer’s work habits. As I search for wiki solutions for collaborative authoring on Agile teams, I’m reminded of this article again and again. There’s no crying in Agile, and having an Agile documentation tool should help with change management. Except, of course, the change management associated with bringing in a wiki. Stewart Mader had great suggestions at the recent WebWorks Roundup: make wiki upkeep part of everyone’s job, make it as easy as email, and make it as sociable and enjoyable as riding the train to work each day. Any other ideas? I’d love to hear them.

I spoke with Ellis Pratt with Cherryleaf in London from my home in Austin for a video interview last week, and the shortened version is available online now.

He had many good questions, ones that I enjoy discussing all the time, such as the future of our profession. One good one was “What will user documentation look like in the future?” Also, “Is there too much reliance on search?” and “What are the blind alleys?”

I’m not sure I have all the answers, but I do enjoy talking to people who “get” it like Ellis does.

Here’s a direct link to the interview, which has slides guiding you through highlights of the the questions and answers.

I really appreciated Ellis Pratt and Cherryleaf giving me the opportunity to talk about the concepts in my book. These types of interviews – video, audio, lunchtime, you name it! – lend more dimension to the book than just flat pages. I appreciate it!

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.

I just read a great post by Rajesh Setty on the Lateral Action blog called 9 Ways People Respond to Your Content Online. Maybe it’s because I’m in the final countdown before my book is permanently affixed to the pulp of dead trees, or maybe it’s because I’m looking at online user assistance tools to see how they can enable conversational documentation, but it struck me that user assistance gets stuck in that first low value category often. Here’s the excellent visual that shows how return on investment increases as the response to the content becomes more and more spreadable, actionable, returnable, and impossible to ignore.

Image courtesy Rajesh Setty

We are told as writers to make our online help scannable, that people don’t linger on it, they just want to find the answer, get in, get out, get on with their work. With the classic online help tools available, we rarely break into that second tier where readers can stop, save (as in social bookmarking), and shift their thinking based on the content.

And the final tier, send, spread, and subscribe, are actions not yet available in a classic help authoring tool. The “send” action can be via email only, and most help systems have to have that type of link specially coded. Spreading a link via social networks is not yet enabled in online help systems that I know of. And how many help vendors offer a subscribe or notification system?

If these response mechanisms are what your audience requires, you may have rethink your Help Authoring Tool selection and look at comment tools, blogs and wikis, and create a help system offers the features that give opportunity to leverage content and engage the readers. I believe Adobe has accomplished these goals with a hybrid approach that offers traditional online user assistance that includes the ability to “talk back” to the help writer via comments on each help topic.

I benefited from their approach this weekend in fact. I have a lot of footnotes in my book that point to relevant web pages and blog entries. I wanted to collect them into endnotes for the entire book. So I searched in the Indesign Support Center site. You can either search their Community Help or search the Indesign Online Help. The Community Help feature is in public beta according to the About page, and they are using a Google Custom Search Engine to “selectively index only the most high quality sites and resources.” I found a series of comments on the topic about footnotes that led me to a blog entry from the lead writer on blogs.adobe.com. His blog entry describes gathering footnotes into endnotes that use cross-references – apparently an old FrameMaker trick! And, to make it even more clear that a community helped this writer, he credits a forum post comment in a InDesign user forum with giving him the answer. Plus, after the blog post was published, another community member commented on the blog entry, giving him a link to the scripts that would automate the footnote to endnote process described in the blog entry. I was utterly blown away. Community documentation at work for me.

What do you think? Are the tools that cater to the needs of technical publications crowd already available? Or are technical writers going to move content to blogs and wikis due to feature demands from their readers?

I gave a webinar this week for Scriptorium that will be available online titled “Documentation as Conversation.” The fact that it’s recorded lets you avoid scurrying around rearranging meetings in Outlook just to attend it. It sold out which was great to hear, but I like that the message and conversation continues through the recording. One of my fun examples was the Wordle visualization of my tags from the social bookmarking tool, del.icio.us.

During the question and answer session, someone mentioned they felt like social media made her feel like we’re becoming paleontologists. I think she referred to my many examples of how to “stalk” your users to learn more about them and their goals, especially if you document software. I search for my product’s name in Indeed.com job listings as well as look for job titles with my product’s name in LinkedIn to learn more about the people I’m writing for. I wrote up the technique in this blog post, Find your user’s vocabulary and use his or her key terms as keywords.

I also had a follow up email saying that people want to know, where should my team start conversations? Or where should we focus our time if we do start? In my book, I talk about phases: Listen, Participate, Share, Build a Platform. I think you should start with listening and monitoring what’s already being said. Next, start by commenting on blogs or by blogging yourself. A baby step towards blogging is to blog on an internal site, behind your firewall, just to limit your audience if that makes you more comfortable.

Also I’d recommend trying out tools that are already installed that you don’t have to maintain and install yourself. For example, I started justwriteclick.com on wordpress.com and paid $10 a year to map my domain name. When I knew WordPress was a good fit for me and my blogging and site needs, I went ahead and found an ISP and installed WordPress myself. And two years later, I’m hooked on WordPress and I’m even attending WordCamp Dallas in a few weeks.

Sharing content is the next step, and the final step is providing a platform for users to bring their own content in. These steps take time but you will learn valuable lessons along the way and hopefully avoid any stumbling or disastrous results. It’s okay to fail, though. You learn new lessons with each attempt and approach.

So keep an eye out for the recording of the webinar, Documentation as Conversation. The price remains at USD $20 and you get to schedule listening to it any any time of the day. It’s an hour long and if you do listen to the recording, feel free to contact me via email with any questions. I am looking forward to hearing even more feedback!