I’m reading (with vigor!) the The State of Community Management Report: Best Practices from Community Practitioners
from the Community Roundtable, and finding so many wonderful tips about content from people who are community managers. I had to start a list of items that are relevant to technical communication and web writing to share. I naturally tend to target technical communications when I interpret the report, but this report is rife with content strategy.

I agree with this statement, and I think it means a positive impact on technical writers and web writers who are paid to create content by businesses.

The percentage of content that is desirable and
feasible to be formally produced versus community-generated
will have a big impact on resource and
budget planning. This aspect is likely to change – often
dramatically – over time, although it should not be
assumed that content should ever be exclusively
community-generated.

I personally haven’t found that completely community-generated documentation will serve most business goals. In the case of FLOSS Manuals, though, the community-generated content meets the main purpose of supporting and documenting  open source software. Still, hiring professional writers makes sense when you need to create content that meets very specific goals for a community, whether your goals are raising awareness, troubleshooting, or learning.

Now, this particular comment puts a bit of a stake in the heart of technical communication’s beloved single sourcing. I like the idea of associated content for technical writers to create. It’s branching into new media, such as audio or video, while still valuing the technical content that you work so hard to create. It’s not that one births the other, but rather the two types can compliment each other.

Instead of directly repurposing content from one format to another, create
associated content. For example, instead of turning a white paper into an
audio transcript, create a podcast discussion about it with the author.

Another line that causes me to press pause and ponder for a bit:

People seldom form relationships with text alone.

Instead, offer images, video, or music as part of the user experience in order to grow relationships. Fascinating.

And finally, the one that might be the toughest for professional writers, copy editors, and technical communicators to accept:

Learn to accept imperfection. Concentrate on making content interesting
and relevant rather than perfect. Imperfection actually allows community
members to better relate to it and engage with it.

And with striving towards imperfection as my excuse, I’ll close out this blog entry and encourage you to read the report for yourself, drawing your own arrows from the quiver and targeting what is important to you.

For this month’s Central Texas DITA User Group meeting we played host to Eliot Kimber. I took some scattered notes, mostly jotting down the great phrases Eliot handed out while nodding and chuckling.

He’ll be doing this presentation as a webinar for Really Strategies, Inc. on March 10th, and you can sign up on the Really Strategies website.

Eliot is explaining why DITA makes sense for publishing outside of tech comm – because most all publishers need to get ePub out of their legacy content. NEED.

DITA should take over everything – Eliot has an evil plan. He tries not to put his pinky to his chin, though. He uses strong statements, though, like:

“No reason to choose any other XML standard but DITA.”

DITA for Publishers is built on/with/using:

• Topic types: article, chapter, subsection, sidebar, part
• Map domain: pubmap
• MS Word to DITA framework – XSLT-based framework
• ePub transform for Open Toolkit
• Pubmamp support for PDF transform, which enables creating quick drafts for review while people offshore the XML-izing of the content

Example of just how exacting and demanding editors at publishers can be: Quark to Indesign migration blocker (years ago) was that a particular hyphen character wasn’t automatic with Indesign.

Eliot on publishers deciding to go with XML: “If they’re really lucky, they have an IT group that won’t help them with decisions on XML solutions.”

What Publishers need that DITA brings: (bold emphasis mine)

• Low cost of entry for sophisticated XML solutions
• Blind interchange of content
• Flexible markup design
• Strong support for modularity and reuse
• Wide support by free and commercial tools

He got tired of reinventing the same thing over and over – DITA for Publishers makes his implementation job easier – more clients farther along a path of success.

Doesn’t DITA require modular writing?
- No

Most people implementing DITA have one topic, one file – but that is not necessary – he could have an entire book as a single XML document with one root “topic.”

Who’s using DITA for Publishers?
- ASTD is using it for their publishing of books and magazines
- Upper Room – Methodist church – publishing arm of major No. American church for books and magazines
- Publisher of test preparation manuals – including TAKS test – using learning and training specializations for test questions as well
- Any Really Strategies client who doesn’t already have schemas (or who is willing to migrate to a DITA-based solution)
He usually can get at least one output that they can’t currently get out of their current XML schemas

Publications are very simple – except when they’re not. One differentiator that publishers can use is the design of the book – unique, attention-getting designs are valued.

DITA enables iterative design and development – when you come across something more sophisticated than the “norm” you just keep adding features – and interchange is always ensured.

Map / Content distinction is essential – chapter, sections, subsections, but publication structures can be very complicated with appendices, glossaries, indexes. Maps can impose the semantic meaning within the context of a map structure. So you may have one kind of division element, but 18 kinds of topic reference (yow, but that makes sense.) Means he can convert easier to generic topics, but add sophistication through the map.

Lots of publishing content is highly modular -

examples:
magazine articles – reusable, valuable, can send through email, post to web
encyclopedias
travel and nature guides – can be recombined in interesting ways to provide additional value – also batch consistency over a large number of pubs makes sense (automated composition is a-okay)
Dictionaries
Newspapers
Sidebars – by its nature it’s a standalone thing
Educational materials such as textbooks
Standards – people make money publishing info about accounting standards, for example

Business rules apply to element types in their CMS – so there’s a practical aspect to article, chapter, subsection, sidebar and their nesting

Bookmap is way too limited for technical manuals that don’t conform to IBM standards

Bookmap doesn’t give publishers what they need, so he built a publication map domain – provides more structuring options, more licensing options (nothing to do with copyright), he can also mix it in with other map domains, e.g. learningMap

structural module vs domain module – you can pick and choose in a domain module the things that are specifically useful

Provides publishing-specific structures, such as “page” – can have a topic with an empty title element

Publishing domains:
+ Formatting domain
- supports capturing of arbitrary formatting (example: 9th grade biology text book – lots of nutty formatting)
- Integrates MathML
-Can embed raw InDesign interchange data
+ Pub content domain – elements contained in typical publications, e.g. epigram
+ Verse domain: markup for poetry
+ Classification domain: container for classifying metadata (specific taxonomy, Upper Room has this for all the ways their content relates to the domain of spiritual “stuff” he used a DITA map for the taxonomy)

General purpose Docx to DITA XSLT transform – authors are writing magazine articles in Word and then submitting. Transform configured by separate style-to-tag mapping. Everything from magazine articles to entire course scripts, all with different configuration parameters. Must have consistently tagged styles in the Word document.

XML-first workflows are pretty rare in the publishing industry among publishers.

Too much variablity in the business process – eight different biz processes through which they get books to publish at an association, for example.

Typify can “remember” where things came from and automate composition, but it costs a bunch.

DITA to InCopy generates InCopy articles from DITA topics – InCopy is used for manuscript preparation (writing with no layout).

The ePub open toolkit plugin generates HTML-based ePub packages from maps
Uses output of the base XHTML transformation type

What he wants to continue after DITA 1.2 is done:
- Documentation of vocabulary modules
- Refinement and extension of tools an infrastructure

Community of DITA for Publishers users is building – he wants to propose it as a DITA Subcommittee once he gets enough community behind it.

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?

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?

Never permit a dichotomy to rule your life, a dichotomy in which you hate what you do so you can have pleasure in your spare time. Look for a situation in which your work will give you as much happiness as your spare time.
Pablo Picasso

Someone pointed out a bit of a dichotomy in technical communication the other day. It was such an interesting observation that I’ve been thinking about it for a while. The dichotomy is between the power of plain old writing skills and the power of “sexier” specialized skills.

What are the specialties?

Directions for tech comm that  Tom Johnson and Alan Porter discuss on their respective blogs is a movement towards videos and screencasting (screencasts category on Tom’s blog) or graphics and illustrating (comics category on Alan’s blog). Mostly the posts talk about how users don’t read the manual (which is apparently okay). Perhaps specialization is a wise direction to take, because it’s a specialty that won’t be taken over by “the crowd” as easily as writing. WordPress.tv, for example, was seeded with 20 professionally-produced how-to videos, and the community can add videos to the site as well. You can mostly detect which were made by professional film-makers, so it would appear they’re employable longer.

Content farms go moo

Since anyone can write, and content farms are impacting the web, filling it to the brim with quickly written, search-engine baited fast-food content, hone more specialized skills in order to thrive in the shifting sands of the web, right? However, content experts like Brian Massey say that all content, no matter the source, is what’s driving the successful websites and web applications today. The written word is still effective with measurable results, and is overwhelmingly more prevalent on the web today, page for page. Mint.com, for example, is a wonderful redistributor and aggregator of banking and investment accounts, a specialized type of content. Mint also creates content, such as the weekly summary newsletter, that encourages you to return to the site. This content is text and numbers, with lovely graphs, but it’s really the numbers that shine.

To summarize

With both sides pointed out to me now, I’m leaning towards the broader content strategy movement. I will help people get content from any source, even if it’s built by a community or (gasp) ordinary users. But I do see the value in video and especially in non-text-heavy mobile content as we roll into the new year and a new decade.

Here’s my observation. If it’s true that bit.ly, the link shortener that’s popular on social sharing sites, has counted over a billion click-throughs per month, then it’s possible that social sharing will overtake search engine optimized content. As noted in 5 Trends That Will Shape Small Business in 2010, “Social search has the ability to eclipse the value of traditional SEO efforts.” A comment counters with the trend to go from text to video, saying clients should “record, record, and then record some more.”

Let me repeat that. Eventually there could be more people reading and clicking through links on social sites than searching and clicking through links in search results. How will that shift change how you create content, and how will you strategically choose the content that you create?

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 spoke with Rachel Potts, technical communications manager at Red Gate Software this week. They have done an innovative, seamless content combination for their Support Center (red-gate.com/supportcenter) to combine Author-it HTML output with technical support articles. Forums are one click away from those articles, and the authors include both technical writers and customer support pros. As she describes it herself, “The Red Gate support site is a help and support portal that comprises content such as product help, a knowledge base, marketing videos and public forums.”

I’m impressed and enjoyed speaking with Rachel about how they combined content from different sources. To integrate their output with the customer support articles, massive XML transforms are built against the Author-it output to populate the custom content management system that runs the support website. The content is not locked behind a support login, though.

Rachel has written an extensive article about their use of Google Analytics on the site, titled, What can web analytics do for technical communications? It’s a great article, one I’d been hoping for, that describes the useful metrics and what to glean from those data points, such as page views, unique page views, exit rate, and time on page. She also extensively analyzes search data. I also appreciated the section on identifying pages that no one reads. Fortunately, they don’t have that problem with their content.

She’s looking for examples of people who are pulling content from multiple authors in different areas in the company and also people outside of the company. Here are the three I sent her.

• Adobe’s community help search is described on this page, and you can link to it to try it from there as well: http://community.adobe.com/help/about.html. It’s described as “This search index includes content such as product Help, language references, TechNotes, Developer Connection articles, and Design Center tutorials as well as the best online content from the Adobe community. Searchable content is chosen by experts at Adobe and in the design and developer communities, meaning you find the focused answers you need faster than with any standard web search.”
• Sun Microsystems has projects where technical writers are gathering different types of content. NetBeans Ruby is the project I heard about at the STC Summit in 2008. Here’s their wiki: http://wiki.netbeans.org/Ruby. They post screencasts and tutorials to http://mediacast.sun.com.
• Cisco has done some remodeling on their support community, for the better, by combining more content: https://supportforums.cisco.com/index.jspa.

I’m interested in hearing your examples as well as talking to people who have cast a wider net to gather content for support sites. What are your favorite sites, either as a consumer or creator of support information?

I’ve been working on some collaborative authoring scenarios for our Agile teams – we’re going from 5 people to 47 people in total who could author external or internal documentation within our two week sprints. Turns out, we likely represent some trends in the enterprise – Forrester just released a report about benchmarking your collaboration strategy.  A quote from the abstract does describe our need to broaden our collaboration to more and more people.

A companywide collaboration strategy was once a nice-to-have. No more. Even in the current economic climate, 37% of organizations surveyed in Forrester’s Q4 2008 enterprise and SMB software survey consider implementing a collaboration strategy important in 2009. Two broad trends are driving this: 1) There’s a critical need to drive information worker efficiency and to manage the unstructured content artifacts they produce; and 2) while the value of improved collaboration is clear, the path to success has become more complex.

Also, I’m finding that we have broader considerations than just the technical publications department for serving up the best content for customers. While researching some solutions, I discovered that most enterprise-level solutions would require a jump from four-figure annual costs (less than 10,000 USD) to five-figure annual costs (greater than 10,000 USD). Or, to go from four-figure costs to four-figure costs while still meeting the author requirements may require an open software solution.

I’m blogging about it because it seemed like an interesting phenomenon. I don’t usually like to write about tools, because I don’t want to seem like I’m endorsing a vendor. And I’m not endorsing any vendors, especially with the new FTC guidelines. But I thought by sharing this on the Internet, I might get some clarity on whether there is a true trend in the field of technical communication towards collaborative authoring environments, and perhaps discover what are the collective forces that are pushing us towards collaborative authoring.

First, some requirements for the system we need.

Consumer requirements

• Must get a known version of the docs that were delivered with a particular software release
• Must output printed books – PDF is fine, previously we used Word .doc files delivered in electronic format however
• Must enable draft content to be available internally for review every week (even though we are on two-week sprints, three of six teams are on alternating sprints so once-a-week publishing, really once a day or on demand publishing would be required)
• Many other items like syndicated content, comments, ratings, web analytics, but these are not “must haves”

Author requirements

• Must fit into budget constraints (this amount is four figures currently)
• Must meet the existing server and client system requirements (Windows-based, with a SQL Server installation available)
• Must be supportable by three tiers: author community of practice, then the members of Agile teams, and then the corporate IT team
• Must enable two authors per Agile team minimally (12-14), ideally allowing all 47 members of production teams to create content
• Must enable concurrent use by authors in two different versions of the product

Possible collaborative authoring solutions

This list is not comprehensive, and I’m sure people would like to jump in with suggestions – feel free to do so. Remember that I’m in the “less than 50 users” category, and that the goal is company-generated user assistance articles, not community-generated articles. Authoring happens behind the firewall, but the content should be freely available once “published.”

Five figures:

Author-it Live: $30,000 (although their website is currently saying there are pricing discounts which make it about $15,000)

Sharepoint 2007 server: $40,000

Author-it to Sharepoint plugin: $25,000

Alfresco (compare to Sharepoint): $20,000 (blog entries hint at the cost)

Four figures:

Confluence: $2200 for 100 users or $800 for 25 users, annual cost (migration could be free depending on what tool you use to migrate content)

MediaWiki: free (migration would require WebWorks ePublisher)

WebWorks ePublisher: Server version $2000/year

Drupal: free (migration could be free depending on the method)

Migration

Migration is completely possible, when given the time to do it. We have over 4,000 HTML files on our helpsite currently. Interestingly, DITA could play into the migration scheme because it offers a universal “translation” like a Rosetta Stone, giving content some fluidity.

1. DITA2Wiki

This is an open source project that takes DITA output and transforms
it to Confluence Wiki, and it could be automated with builds. Download
it from http://sourceforge.net/projects/dita2wiki/.

2. WebWorks ePublisher

This is a proprietary software tool that has an annual cost, available at WebWorks.com. I have a free version that I am using and it works, with lots of customization work in the designer we could get nice output, but at a cost. The Express version is $300 a year, but it would not give us the customizations on output that we would need. The Pro version is $800/year, giving us design, but not ongoing builds with the tool. The Server version is $2000/year which gives you designer plus a command line interface that could automatically build wiki output every time the product is built. WebWorks outputs to MediaWiki, Confluence, and MoinMoin. I have only tested output to Confluence, which works great.

3. Confluence DocImporter

This tool, Doc Import, is built into the Confluence wiki itself and offers a manual web-form-based import of Word documents. The pilot work I did worked really well. After we worked on a sidebar table of contents, however, no additional Word docs can be imported due to some setting where it won’t override existing pages. I would do more work on this method because the results are at first glance even better than those from WebWorks ePublisher. But, this method does not offer automation (unless we find an API that automates using  DocImporter).

4. Drupal’s HTML Import

This method is as-yet untried for our content, but the idea is that we could take our existing HTML output, which is pretty well-structured, and use the Drupal Import HTML module on the entire site, a section at a time. I think this method would work, although it is more than a bit labor intensive for over 4,000 HTML files and all the links and images involved.

Topic-oriented, web content

There are two other options that come to mind when mentioning collaborative authoring. They are Acrobat.com at $390/year and Google Docs, with no price. But those options do not offer a topic-oriented content management system that you could use to output web content – instead you get bundles of PDFs or Word documents. I’m not sure either of those are viable for our requirements. But maybe I need to be thinking outside of the box?

What are some of your favorite collaborative authoring tools, and why?

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.

The phrase “content curator” was one I had to define in the glossary of my book. It seems now that content curator is an idea that others are writing about as well.

RJ Jacquez, Adobe product evangelist, tweeted a link to an article about Content Curation on the site Social Media Today titled “Manifesto for the Content Curator,” written By Rohit Bhargrava. In it, he describes his definition of a content curator: “A Content Curator is someone who continually finds, groups, organizes and shares the best and most relevant content on a specific issue online.”

Photo courtesy ingorr on flickr

I think that professional writers and technical writers should consider a move towards this role. We already search for and find the best content, sift through loads of content, discard poor content, and publish the most worthy content whenever a software release goes out. This description also sounds like something a content strategist would do as part of their analysis of the content.

What I found fascinating after the article had been out a few days was to read one of the comments, where the commentor seemed to think that tasks related to content curation should be automated. He referenced two sites that curate content by classifying it and rating it, mahalo.com and oneforty.com. He saw content curation as a great opportunity for software developers and entrepreneurs.

What do you think? I’m guessing my blog’s audience would protest mightily. Do you believe that content curation can be done by algorithms of rating and relevancy? Or should this job be reserved for specialists?