Previously, D. Leonard and J. Gilsdorf (1990) presented 45 instances of questionable usage, in full-paragraph contexts, to both academics and working business executives. These usage elements included sentence fragments, assorted punctuation problems, pronoun-antecedent (dis)agreement, and various examples of questionable word choice. Their intent was to assess the "botheration level" of each usage "error"; their conclusions were that: 1) academics are (nearly) always bothered by usage "errors" more than executives; and 2) usage elements that bothered survey respondents the least were evolving over time into acceptable English usage. Setting aside for now the problem of ongoing language change and its causes, the article focuses on the problem of predicting what will remain unchanged in language-usage rules and proposes an explanation for why certain rules will remain unchanged. This problem is critically important for anyone who is mentoring the writing of younger people, people whose primary audience will not follow our rules, but rather the rules of the next generation of readers.

Explanation is the bread-and-butter activity of any technical communicator. We explain things for a living, but how well can any of us explain the nature of explanation itself? What makes technical explanation different from persuasion or narration? Web-based instructional systems have pushed us away from traditional kinds of paper-bound explanation. In these new realms, anything better than hit-and-miss success requires a clear sense of basic principles. With that in mind, I discuss the basic logic of explanation first proposed by the philosopher C.S. Peirce in the 1870s, and more recently extended by J. Hintikka (1998).

Technical writers, for the most part, write user documentation of some kind. However, they also have skills that might enable them to also serve as user-advocates on product development teams and testers of prototype systems. In the computer hardware and software industry, they have the additional skills needed to develop online help tools, to design user interfaces, and to write system and error messages (J. Fisher, 1998). Fisher's recent survey of (Australian) technical communicators showed that some are employed in such tasks, but not widely so. She reports, for instance, that only 38% were consulted by developers about error messages, only 32% actually wrote error messages, and only 13% reported that they had some role in system testing (J. Fisher, 1998). A question emerges out of such results: is there really any necessary and supportive connection between the process of explaining a product to a user and the original process of developing that product? As technical writers looking to expand our roles [and salaries], we would like to say yes. But, in fairness, we have to admit our bias. We need to check such biases against other, independent evidence. The article interfaces this question with a parallel question in the philosophy of science: is there any connection between experimental test results used to "sell" a theory to a scientific audience and the original process of developing that theory?.

Some years before electronic mail and Web-based hypertext became important features of professional communication, Robert Pirsig observed that information has always had higher value if it was organized in small chunks that could be accessed and sequenced at random. The paper discusses dynamic and static communication in electronic media.

INSIGHTS about professional communication may come from odd and unexpected places. McCloud's Understanding Comics (hereafter UC) is a case in point. Despite the juvenile connotations evoked by any discussion of comic books, the theory of visual communication presented in UC arguably rivals the best of contemporary semiotics (that is, the study of how we make meaning out of gestures, words, paragraphs, pictures, and so on).

Looks at the application of minimalist principles in technical documentation.