Systems that Get Better the More People Use Them
In Publishing 2.0, Tim O'Reilly says Web 2.0 is "any network effect that makes a system better the more people use it." Web 2.0 isn't just user-generated content; it's harnessing the collective intelligence of your users to make your system better.
O'Reilly's definition is intriguing because it's the opposite of the natural law of use. Your car doesn't get better the more you use it. A music track doesn't get better if more people listen to it. Your bank account doesn't improve as more people use it. Your feet don't get better the more you use them. Very few things actually get better the more you use them. Not Web 2.0. It's almost paradoxical. The more people who use it, the better it gets.
O'Reilly gives two main examples:
- Google. With Google, every time a user makes a link to another site, Google uses that hyperlink to better inform its search algorithm.
- Amazon. Borders and Barnes & Noble have the same stock of books, but Amazon integrates user reviews and commentary to add more value to their literary collection. With each review, the site gets more valuable.
O'Reilly also mentioned eBay and Craigslist. With each system, the more people use it, the better it gets. O'Reilly also has interesting research on publishing and digital libraries, but I'll save that for another post.
The question for technical writers is not how you can enable user-generated content with your help, but how you can make your documentation better as more people use it.
I wish I could say I have lots of cool ideas on how to do this. I don't, maybe you do -- refine search results based on user queries, allow users to comment on topics, sort topics based on popularity of views, enable users to contribute their own topics, configure search results based on topic viewing time, provide user community, yada yada yada.
These ideas aren't new or particularly interesting. Partly it's because they're still so pie in the sky, how- -do-you-even-do-it type features. Next I'll suggest telepathically downloading hotspots in user-brains to note the kinesthetic, verbal, or auditory preferences of your users based on the lobes that light up.
Yet we're at a point technically where many of these features exist or are available. Our problem is that most help authors aren't programmers, and few programmers get jazzed about coding help tools. When's the last time you saw an open source help authoring tool that was specifically designed to create help systems?
(Okay, I did see one last week — called PHP Manual Creator, but it looked really primitive.)
In contrast, look at the explosion of social networks, blog platforms, video sharing tools, and countless other killer web 2.0 apps. Inevitably, help systems will also migrate more towards O'Reilly's idea of Web 2.0. But rather than seeing these blow-your-mind-web-2.0-type tools emerge from the help developer community (i.e., all those companies who advertise in Intercom), I think the next-generation tools will come from web developers and designers who create them for another purpose. We'll simply repurpose them to deliver help content.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.