http://tc.eserver.org/dir/Articles/Reviews/Documentation A listing of the most recently indexed works about Articles and Reviews and Documentation in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Articles/Reviews/Documentation http://tc.eserver.org/34630.html http://tc.eserver.org/34630.html 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. http://tc.eserver.org/32093.html http://tc.eserver.org/32093.html A very brief review of the first edition of Edmond H. Weiss’s How to Write a Usable User Manual. http://tc.eserver.org/28138.html http://tc.eserver.org/28138.html Documentation projects require a significant amount of coordination and planning, and managers often find themselves faced with the challenge of successfully integrating a range of new elements including international legal requirements, new players, budgets and scheduling demands to make a product successful. Most often they look around for solutions to develop an effective strategy for their documentation projects that places control in their hands. http://tc.eserver.org/27589.html http://tc.eserver.org/27589.html In Agile Documentation, Rüping gets to the heart of the documentation dilemma, offering a two-word solution: minimum necessary. http://tc.eserver.org/25848.html http://tc.eserver.org/25848.html 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? http://tc.eserver.org/22922.html http://tc.eserver.org/22922.html 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. http://tc.eserver.org/22925.html http://tc.eserver.org/22925.html 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. http://tc.eserver.org/22927.html http://tc.eserver.org/22927.html 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. http://tc.eserver.org/22924.html http://tc.eserver.org/22924.html The editor and principal writer of Producing Quality Technical Information (1983) responds to the commentaries: answering questions about the sources of PQTI; discussing what the System Information group at IBM's Santa Teresa Laboratory were doing about usability from 1979 to 1983; comparing the predecessor nine 'ease-of-use factors' with the seven 'qualities' of PQTI and the nine 'quality characteristics' of Prentice Hall's subsequent editions of PQTI, published under the title Developing Quality Technical Information; and revealing his own motives and thought processes in working on several usability initiatives in the laboratory at that time, including the publication of PQTI. http://tc.eserver.org/22910.html http://tc.eserver.org/22910.html 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. http://tc.eserver.org/22909.html http://tc.eserver.org/22909.html 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. http://tc.eserver.org/22344.html http://tc.eserver.org/22344.html Page's book makes the first attempt to open the door to examples of tables of contents of P&P from a variety of organizations. He also makes an admirable attempt to position and show the P&P analyst/writer as more than a scribe, as a leader who adds value by formulating best P&P practices in collaboration with others for their organization.