Earlier this week I posted about how good product documentation can sell a product, but today I came across “Manuals, conversations, and RSS” by CTO Sean McGrath, where he talks about playing “a well known IT adventure game known as “catch the randomly recurring problem in the mission critical system”.” I’m sure many of you IT adventurers have played this game as well.
He estimates that his information seeking time is being spent in these areas:
10% Reading vendor manuals
20% Googling, then reading
70% Reading developer blogs, user mailing lists etc. Of this 70%, he further breaks it down as:
RSS feeds: 20%
RSS-only search engines: 20%
Blog surfing: 30%
Connecting to conversations, that’s what it’s all about. What an interesting look at two different approaches to getting the info you need to solve a problem. Perhaps debugging requires more detailed information than setup and administration as the previous post talks about? Still, it helps me realize that product doc doesn’t always provide for every user’s needs.
That said, we should constantly strive for some good combinations of deliverables and delivery methods that can work for a broad range of needs. For example, the concept of a DITA/wiki combination offers structure to an editable web site that both the product developers and end users could edit and add to in a structured way. We’d need an authoring tool that’s like a webform that can validate XML against a DTD, and a wiki that can accept the DITA XML topics and display them as navigable, editable wiki pages.
Another neat combination that’s already out there is user-supplemented help, as described on the Usable Help blog, where the help itself can contain comments and conversations occur through those comments. As Gordon Meyer says, it “allows end-users to communicate directly with the developer, and more importantly, with each other about the quality of the documentation and the features of the software.” Well put.
While I can’t always retrace the exact steps I take to a certain article, I like to explain how I find some of these links, and in this case, I found it as a link from “Exploring Agile Methods for Web Design in a post titled ” Why QA professionals throw away manuals and blog instead.”
I won’t ignore the fact that the blogs at talk.bmc.com are also the opportunity for conversation with our end users. I’d love to hear more about your thoughts on documentation, our products, BSM, ITIL, you name it, and we’ll talk about it. Think about ways that you can open conversations with your end users when you roll out new IT applications. What are some of your ideas?