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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.