After another unintentionally long hiatus, we’ve posted a new episode of the podcast. In it, we discuss what we’ve been up to and what we plan to do in the coming weeks. Then, we discuss a topic that is very important to Aaron: usability.
You can listen to the podcast here, or use the embedded player below.
Regardless of what we’d like to believe, technical communicators aren’t perfect. Neither are the development and project management teams with whom we work. Sometimes we get things wrong and that makes it into the final release of the documentation. Or, for whatever reason, something gets missed.
Nowadays, most documentation is distributed electronically — as a PDF, HTML, a help system, or all of the above. So, it’s a lot easier and cheaper to issue updates to documentation. In a number of shops in which I’ve worked over the last few years, updates and changes and corrections have been slipped in rather stealthily: replace the old electronic version with the new.
The other day, I was browsing the documentation at the Web site of Red Hat. I noticed something interesting while I was there: a link to documentation errata. I haven’t seen something like that for a while, and it’s a nice touch.
The errata page links to updates for various guides. There are also detailed instructions on how to submit corrections using Red Hat’s Bugzilla tracking tool.
How do you deal with errata? Feel free to leave a comment.
This blog post asks whether or not single sourcing is the best option for creating documents. I’m not sure that I fully agree with everything in the post, but something that the author wrote struck a chord:
I know a single source of content will save me a lot of work. But for other people in the company it won’t. It will mean more work for them, not to mention a very steep learning curve, an investment in software and a strong training commitment. It will save me lots of time and effort—in the long run—but it’s going to double the work effort of ten other people. Where is the benefit?
Thoughts? Feel free to leave a comment.
A few posts back, Aaron discussed how “effective usage as a far more important factor for realizing value in a software deployment than features and functionality”. That’s not only the case with software, but with Web services, too.
This short article points out:
Online retailers can win customers by maximising usability rather than lowering prices
The benefits of well-planned usability are obvious. Users are able to get more done quickly and easily with a clean, easy to follow interface. It’s not only on the Web, either. It applies to the desktop, too.
If you want a view of this from the perspective of a technical communicator, then read this post by Gordon McLean. It goes into some detail about the usability process he follows.
As I pointed out in a previous post, an OASIS sub-committee was formed last year to explore using DITA for enterprise business documents. It’s an interesting concept that’s been enthusiastically received. Aaron and I are hoping to talk with a couple of people involved in the sub-committee at DocTrain West this May.
Of course, DITA isn’t the only XML kid on the block that can be used for documents other than manuals and the like. DocBook, too, is very capable. Technology book publisher O’Reilly has used DocBook for a number of its titles, as does (at least according to this page) Sitepoint.
But what are the challenges facing anyone who is interested in bringing DocBook to a wider group of users? Fabrice Talbot of LiveTechDocs discusses just that in this blog post. Talbot points out something that the folks on the DITA for enterprise business documents sub-committee have learned:
An important factor in driving user adoption is the availability of software that implements the standard. It would be interesting to see whether big software companies would jump into the bandwagon… Unless the open-source community comes to the rescue!
Another important aspect for user adoption is regularly overlooked: usability. Too often, software vendors release poor GUIs designed for engineers or technical-minded people. As a result, non “XML techies” face a steep learning curve. The creation of their first XML document is often a daunting and discouraging task.