I finally did it, I wrote my first article for the Demand Studios content farm site, eHow. I wasn’t playing the part of a content farmer, though, but rather a farm worker, writing an article for little pay (compared to other rates I have earned as a professional writer).

I signed up for Demand Studios a few months back. There is a company called Pluck here in Austin that was acquired by Demand Media in the spring of 2008. What drew me to them in particular was not only the local connection, but also a fascination with turning search engine optimization on its ear. I first learned of these methods for content creation from this Wired article, The Answer Factory: Demand Media and the Fast, Disposable, and Profitable as Hell Media Model. Basically Demand Studios analyzes what phrases are searched for and then enter an article request in their database. There are currently 15,000 articles waiting to be written in their system. The pay for those articles is from $15 to $7.50 or less, and there are some assignments that offer profit sharing based on the numbers of views, apparently.

As a pro writer, I was dead set on following the style guide, knowing that attentiveness to the guidance given is part of the battle in producing good content. In their system, when I “Claimed” the article, it wasn’t immediately apparent which template I would be writing to, which made me a little nervous about attempting it in the first place. After clicking the article to claim it, though, I found that it was the About template. The guidelines were very clear – the About type required five sections with one-word section headers and the first section had to be titled Overview and contain about 75 words. The rest of the sections could contain more than 75 words but at least 50 words were necessary, and overall the article was targeted for 400-500 words. Quite structured.

The web-based authoring forms were easy to use, though it did not include a word count. I found it easier to get word counts in Textpad and then copy/paste the text into each section.

They’ve also very recently introduced an image library that you can search for images, the use of which is encouraged. You could add an image to each of the sections if you wanted. To my poorly trained eye, they seemed adequate but not too glossy, and none of my searches found quite the perfect image, but I included two anyway. They intend to allow people to upload their own photos, which I would have done in a heartbeat as I had one or two that would have been just right.

To my relief, the article I submitted by noon on a week day was approved by early morning the next week day.

It took me about 2.5 hours to write a 500 word article, I’m not proud to admit (or perhaps I should be proud of the quality that comes at that speed?) So my hourly rate for the article was right around $6.00 per hour. At least I didn’t have rewrites (she says sheepishly.)

To reflect back, I did the article because I wanted to see what the authoring system was like, and experience for myself the process of writing in such a system. To be sure, it’s easy to demonize such a system when you’re accustomed to higher pay for content creation. There’s a great interview on ReadWriteWeb by Jay Rosen, who talked with Demand Media founder and CEO Richard Rosenblatt, and it offers both sides of the issues surrounding content collection and the future of the web. I don’t want to take sides by sharing my experience. I just wanted to collect information based on the writer’s experience.

What do you think? Are content farms cluttering the web and driving down writer’s pay? Or is there an entrepreneurial opportunity here that offers a low barrier to entry for content creators any where to earn pay for  populating the web with content that’s already being searched for?

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 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 attended two days of the WebWorks Roundup here in Austin this week and served on a few panels. I enjoyed signing books as every attendee got copies of books from XML Press. It had featured speakers like Tom Johnson and Stewart Mader as well as sessions with Lisa Dyer and Alan Porter to name a few. Here are my summary take aways from the sessions.

Wiki adoption

Stewart Mader is a wiki consultant, probably the most experienced, practical, and sensible wiki adoption expert available today. His message about wiki adoption resonated with me as I look for collaborative authoring solutions for our Agile teams. He said, if you look around the enterprise, people have high adoption of email for their daily business tasks. In the adoption phase for a wiki or collaboration system, you can tie a wiki to email conceptually as this ubiquitous useful way to get work done. If you think about it, more complex systems have a higher learning curve, so people default back to email to get into their comfort zone. But, sending email messages is an isolating experience – email doesn’t let you work together collectively like a wiki does.

For example, working in the shared space of a wiki is like using light rail to get to work. He has made friends on the train he took each day years ago and he’s still friends with them today. In other words, being in an environment that enables social interaction is more powerful. He says to think about the business process a wiki affects – do not just apply what the Internet says to do with a wiki. The biggest and most powerful collaboration going on with wikis in the enterprise is group collaboration – small groups. You don’t want one-off contributions once, you want repeated collaboration and repeated use, as frequent as email and as a simple core tool that they use for everyday business. Preach it, brother!

He also talked about measurements to indicate that adoption is successful. One of the biggest dangers he sees is counting the number of pages created when adopting a wiki. Don’t do it! Better metrics are measure per time period or per some other unit:

Views                    Day

Revisions      per       Page

Comments                 Unit

Tags                     Type

Automation – 1001 Nightly Builds

Some of WebWorks’ customers gave talks and a panel discussion about automating software builds using WebWorks Automap. These were great eye-openers and my ears perked up because they were writers working in Agile environments. They have to release in tandem with internal development cycles, so they automated as much as they could. One doc group used to have a 15 page document on how to create a PDF complete with screenshots for all the settings. Mary Anthony from Palantir said their writers have to document 4 user interfaces, 3 admin GUIs, more than 12 servers and an API, and they used advanced techniques such as text insets in FrameMaker. Using WebWorks, another writing group had automated PDF generation, wiki output, plus HTML output, all from Framemaker source files.

This was interesting to me – they found there was a true documentation domain and it was hard for someone who usually builds software for them to put together docs. Terms like cross references, text inserts, and so on, were foreign to their build engineers. They don’t even have the concept of “book” as a collection of chapters with a TOC in Framemaker. Even using a Windows server to automate builds was outside of the build engineer’s knowledge.

I learned about a tool called Apache Ivy, which is an agile dependency manager. Using this manager helped them integrate their documentation builds with the product builds. Mary Anthony explained that Ivy waits for the outcome of another build – like a refrigerator holding chocolate pudding, Ivy opens the fridge door and gives the build process what it wants (the chocolate pudding, or the fine documentation).

Overall a great couple of presentations about automation from which I learned a lot.

Blogging and Web 2.0

Tom Johnson is a blogger and technical writer and likely the most subscribed-to blogger in our particular tech comm niche. He gave a great talk based on his blog series, Seven Deadly Sins of Blogging. In case you’re curious, the sins are being Fake, Irrelevant, Boring, Unreadable, Irresponsible, Unfindable, Inattentive. (I’ll link to the rest once he has the blog posts finished.)

He had great pictures representing each sin. My favorite quotes were from Penelope Trunk (The Brazen Careerist, Blogs without topics are a waste of time) and Stephen Fry’s blog entry, “Don’t Quote Me“.

This session was a great starting point for our next panel about Web 2.0, although we mostly talked about blogging. The Technorati State of the Blogsphere 2009 report came out yesterday, so it was useful to talk about some of the findings from it (73% of bloggers use Twitter as compared to 14% of the general population, for one.) I enjoyed talking with Alan Porter and Tom on this panel and I may have asked as many questions as I answered. All in all, a great two days of discussion and presentations.

I have neglected to excerpt and link to some of my posts from the Duo Consulting blog. I’ve taken a break from writing for them for a few months while finalizing my book, but looking back at these posts, I wanted to share them with my readers! So here goes.

It Ain’t All Business: Using Social Networks for Good

When the social media groundswell turns altruistic, the results can be amazing. Here are two examples of both large and small differences made with a few simple connections. Connections made all the more quickly and with a higher rate of trust with the use of social media tools like social networks and Twitter.

Wanted: Good Home for Good Dog

Photo credit: Jim Sneddon on Flickr found using Flickr-Storm. More…

Web Content Mistakes and Worst Social Media Campaigns

We’re becoming more accustomed to correcting small-ish errors on wiki web pages when we come across them. I catch myself looking for an “Edit” link on other people’s pages, but of course not all web pages are editable. But that habitual reaction has me wondering about web content mistakes and how best to correct them.

What’s the biggest web content mistake you’ve seen (or done?)

Michael Silverman told us about the six-year-old news article that went out due to inaccurate automation techniques, causing a 75% drop in a company’s stock price before it could be corrected, in Save $1 Billion with Web Content Management! Now that is a big web content mistake. More…

Terms of Contention: Who Owns Uploaded Content?

Terms of use and privacy policies, how often do you read these terms before agreeing to them? Most of us would admit we don’t read the fine print even when it’s prominent large type. But when a community member does pay attention to a change in the terms of service and gets 100,000 other people to pay attention also, you’d better believe that the originator of the terms and policies are going to take notice. That scenario happened just last week for members of Facebook, one of the largest social media sites with 175 million active users and the most visited site in January 2009 with 1.2 billion visits according to Compete.com. More…

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?

Wow, just got a print copy of The Twitter Book
by Tim O’Reilly (@timoreilly) and Sarah Milstein (@SarahM, user number 21 of Twitter). Thanks go to Andy Oram, @praxagora, for referring me to it after he read a draft of my upcoming book.

The layout, form factor, full-bleed color page numbers, and color screenshots and photos (Twitpics) throughout the interior are just wonderful. This design combination makes it an excellent hand-held object, worthy of being print-based! I’ll keep this one out in my living room. But I’m kind of nerdy that way.

It has important and useful information about Twitter (www.twitter.com) and why it’s so powerful. Just thumbing through it I found two things I didn’t know about Twitter (and I’ve been on Twitter as @annegentle since early 2007.) One is, it really is a big deal that Twitter removed the setting that allowed you to customize which @username replies you saw and your followers saw. There used to be three settings in the Settings>Notices tab (page , now there are none. But Twitter reversed the original policy decision, and Read Write Web gives a graphical explanation (it’s strange enough that it needs explanation.)

The second informative tip is that for the most part, people tweet the most on Tuesday, Wednesday, and Thursday. And most people, if they don’t see your tweet in the first five minutes of you posting it, won’t see it at all. I bet that the more uptake we have desktop grouping helpers like TweetDeck, the longer that tweet click-through duration will last. But even with better grouping so that you don’t miss tweets from people you really want to read, as more and more people join Twitter, it’s harder and harder to ensure you get the information you want. So you might want to think about using TweetLater to post a slightly re-worded micropost at another time.

I have to admit, I do like Chris Brogan’s idea of using the hashtag #getoffmylawn for celebrities who use Twitter in an annoying way. But better yet, have more and more people read The Twitter Book to get better and better at their Twitter use and micropost writing.

And finally, words to live by, in Chapter 3 “Hold Great Conversations.” On Twitter or any other community and communication site, it’s not about you! The best part is about contributing to the community – make a positive impact. “…the more value you create for the community, the more value it will create for you.”

Photo courtesy lollaping
I finished my presentation about Climbing the Levels of Collaboration for the Collaboration Institute at the STC Summit and I’m so excited about it I can’t stand it! True confession: I was up until 1:00 AM finishing it up and uploaded it quite late.

I found this great collaboration exercise that I’ve incorporated into the session. So we’ll be drawing with Crayola markers. Maybe even collaboratively. I’m hoping for quite the Back of the Napkin experience.

This session walks through the different ways you can collaborate with your users (and co-workers) especially when wikis are enabling the collaboration. I’ll be talking about Book Sprints and FLOSS Manuals and tell stories from my experiences. I was inspired by the examples of amazing group accomplishments described in Clay Shirky’s book, Here Comes Everybody: The Power of Organizing Without Organizations. While shopping around the ideas for the talk, I emailed people and asked what they thought of this description:

Groups can take action even quicker than ever before in history thanks to tools that amplify group communications such as wikis, blogs, and instant messaging. There are three distinct levels of collaboration that a group can attain and what they accomplish directly correlates to the level of collaboration.

People I talked with definitely wanted to know best practices for wiki authoring techniques. One person even wanted to know how to incorporate user-generated content into their help system. I’ve heard that request before – such as, how could you import wiki content into Robohelp? Also, what I learned at last weeks’ talk was a high number of people wanting recommendations for wiki engines. There are over 90 to choose from on wikimatrix.org. Eep. Writers also wanted to how to organize content on a wiki. I won’t promise to have all the answers or any of the answers but I am looking forward to sharing my stories and hearing yours.