In recent years, an emphasis on quality has emerged in a variety of organizations and in several fields, including technical documentation. Producing Quality Technical Information (PQTI) was one of the first comprehensive discussions of the quality of documentation. An important contribution of the book is in identifying quality as multiple, measurable dimensions that can be defined and measured (previous views of quality identified it more as some elusive thing that could be identified if present but was difficult to articulate and describe). Despite its contributions to the quality discussion, PQTI runs the risk of simplifying the quality process, reducing quality to a simple checklist that information developers can use to develop effective documentation. PQTI fails to address the fluid nature of some aspects of quality: some dimensions that are important in assessing one document may be less important or irrelevant with other documents. Additionally, PQTI falls short of accounting for the larger contextual framing of documents--that the importance of individual dimensions of quality changes depending upon the audience, context, and purpose of the document.This commentary suggests that all quality efforts should be grounded in customer data and user-centered design processes, and that we should learn to better differentiate among quality dimensions, determining those dimensions that are essential to customer satisfaction and those that are merely attractive. Through increased attention to developing the quality of information, organizations can better differentiate their products and services, facilitate greater productivity, and increase customer satisfactions, all significant activities in an increasingly competitive marketplace.
Online materials, as Johnson-Eilola points out, too often provide speed but neither learning nor conceptual information. Minimum information is often provided in help systems because there are no resources to provide more. But the result is often a system that, without any conceptual information, provides little more than help that is so obvious that it ceases to be helpful. Even when resources are constrained, help systems should, at a minimum, refer to external sources that can help users with important concepts behind the tasks they are trying to perform.
Offers a strong recommendation to read Anne Gentle’s Conversation and Community: The Social Web for Documentation, which provides tips for incorporating wikislices, screencasts, and comment/feedback systems, into your user assistance.
Dr. Bernadette Longo, Ph.D., uses the metaphor of devalued currency to trace some of the roots in technological history for technical writing's lack of intellectual and cultural capital. She ingeniously incorporates early threads of management and industrial technology, like the formation of the railroad, in an attempt to contextualize her research. Academics must view Longo's text, Spurious Coin, as just one branch of what must be a webbed tree of intersecting social attitudes towards knowledge definition and science. In understanding the gaps in Longo's narrative, people interested in technical writing might find her book to act as a launch pad for better defining the questions guiding their own research. In this review, I will focus on some of the important gaps I see in Longo's research methodology as she historically situates the emergence of engineering as a discipline and then as the determining factor in technical communication's subjugated position within the academy and industry.
This review strongly recommends DITA 101 for its clear presentation of DITA basics, with practical examples and easy to understand language. Previously, authors and managers would need to have read the full technical specification to attempt to gather such information.
In past issues of JCD, we have employed graduate students in rhetoric and technical communication to provide their point of view on new books in the field. In this issue's book commentary, I have taken this opportunity one more time as students in a graduate seminar at Michigan Tech - Histories and Theories of Technical Communication - read, discussed, and then responded to Bernadette's Longo's Spurious Coin, A History of Science. Management, and Technical Writing.
What is minimalism? Is minimalist documentation 'risky,' and if so, what can be done to mitgate the risk? Was the structure of Windows 95's Help based on John Carroll's Minimalist Model or was 'the result' more a Microsoft business decision -- or a bit of both?
This paper examines the four kinds of invisibility Johnson-Eilola associates with minimalist help systems: fast information access that reduces user reflection and questioning, impersonal writing style that assumes the Shannon-Weaver communication model, narrow scope that leads to training but not teaching, and interface designs that oversimplify user tasks. For each of the four, the paper questions Johnson-Eilola's conclusions. Ultimately, the problems with truncated online help systems may disappear, as help systems are increasingly linking to the web, where adequate conceptual information is often supplied and opportunities for a social context for help are available.
Soon MadCap Software will be releasing the next major version in the Flare product line, Flare V5. I’ve been beta testing Flare 5 for a couple of months now, and there are some great new features in Flare 5 that you are going to love. In this review, I want to point out some of my favorite new features, as well as some of Flare 5’s other great enhancements.
I had some time today for testing the RoboHelp Packager for Adobe AIR. I kept notes as I went. I would be flooding the Packager forum with threads after exercising the Packager, so I thought it would be better to not be the kind of guest who makes himself at home to the point of leaving his clothes and dirty dishes strewn all over the house. Instead, I’ll provide my critique here in my own space.
Wikis are becoming entrenched in the documentation world. But there are few books that cover how to use them effectively. If you’re looking for a step-by-step guide to using wikis to create and deliver documentation, Writing in the Open isn’t it. It is, though, an interesting and potentially useful set of best practices.