Web 2.0 has revolutionized the way society uses the Internet. Whether it’s Wikipedia, YouTube, Twitter, or LinkedIn, we’ve moved from passive readers to active contributors.
Given this fundamental change, why is it that most technical communicators are operating as if Web 2.0 never occurred? Based on what I’ve seen, most writers haven’t embraced the collaborative model that is commonplace with Web 2.0. Why? Here are a few guesses:
- Some of the web sites are relatively new. Twitter, for instance, has really only taken off in the last 18 months. Most writers haven’t figured out whether to use sites like this and how to use them in their jobs.
- Our tools haven’t fully embraced Web 2.0. The tools that technical writers use don’t fully take advantage of Web 2.0. RoboHelp’s newer Help format, AIR Help, does permit users to comment on a given topic but it doesn’t allow writers to moderate those comments. To me, this is “Web 2.0 lite.”
- Slow acceptance of social media by technical communication departments. Marketing people have fully embraced sites like Facebook, LinkedIn, and Twitter. But from what I’ve seen, technical communication departments appear to be taking a “wait and see” approach when it comes to leveraging these technologies.
Of course, there are organizations that have taken full advantage of social media—more on this later. But I believe these organizations are the exception rather than the norm.
Too bad. I believe that incorporating Web 2.0 technologies into technical documentation could make our content better, foster more dialog with our customers, and change—and improve—our careers.
I have worked as a
That’s because we’re so busy trying to embrace minimalism, get budget to put modern tool chains in place, reuse content, customize DITA output, and on and on. Still dreaming about that “universal semantic ecosystem”.
The developers of an SDK I’m documenting really want user comments on topics–I’m looking into ways to implement that with DITA source. (AIR DITA-OT plug-in?) There’s really a lot of value in a “community” aspect to developer docs. Links to the docs from a collaboration tool doesn’t make it. 😉
I think Julia’s right about the time problems. In my shop, we deal with it by trying to have good liaison. I interface with our web team regularly, and we are working on plans to make our CMS interact with the web CMS so we can push content out when it’s appropriate.
Some of that process will involve the interactivity of Web 2.0, some won’t. Depends on whether it’s useful or not.
Also, for technical information, I think Web 3.0 is much more interesting than Web 2.0. 2.0 is basically a marketing concept, while 3.0 brings real technological advantages that help us to organize and access information in new ways (like ontologies). While the jury is still out on how “semantic” Web 3.0 is really going to be, I’m looking forward to it in the hopes that evolutions in DITA will keep pace and help us move into new spheres.
Thanks for your feedback. In response to Julia’s first comment, I also worked at a company that converted all of its RoboHelp and FrameMaker files to DITA and it took months and months to successfully complete the job. So I understand that writing departments can only tackle so many initiatives. On the flip side, I often hear writers say (complain?) that they haven’t met their users. Web 2.0 could at least help with improving this dialog with users.
Robert, you’re right. Social documentation is a great solution to that problem.
So much depends on the culture a technical writer inhabits. I wasn’t a technical writer at Texas Instruments, but knew several and worked with the several teams managing information design. That engineering-driven culture was all about dynamic, semantic structure of information, files, pages, everything! They went a step further than most companies, and considered their information to live not only on their site, but off-site as well, with the result that they designed to meet those needs.
As a web content manager, I helped make sure the products I was responsible for representing were optimized for semantic comprehension, and well-integrated into several in-house information management tools (parametric search, literature management, content taxonomy, etc.). For someone with her online roots in IA and cataloging, it was a heady experience!
On the other hand, I’ve worked in other cultures where semantic design and search were the last considerations in any content/feature discussion. For example, I once consulted with a telecom firm that seemed to follow a “if we build it, they will come” approach, and felt that their business-centric taxonomy should and would be absorbed by those users who “really wanted to learn something” from the site. Pretty bad user experience. A sr. technical writer, well ahead of her time back then, fought in vain against this attitude.
I guess my point is that technical writers may know what they need to do, but be unable to implement it. I suspect there are many voices crying in the wilderness for semantic, easily engineered data for their sites and apps.