http://tc.eserver.org/dir/Articles/Writing/Information-Design A listing of the most recently indexed works about Articles and Writing and Information Design in the field of technical communication (and technical writing). 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/Writing/Information-Design http://tc.eserver.org/35787.html http://tc.eserver.org/35787.html Structure is a key component to anything that you write. In this blog post, Scott Nesbitt discusses the importance of structure in the context of using the LaTeX typesetting language. http://tc.eserver.org/35321.html http://tc.eserver.org/35321.html One page or separate pages? When faced with that decision, ask yourself these questions: How much do people want in one visit? How connected is the information? Am I overloading my site visitors? How long is the web page? What’s the download time? Will people want to print? How much will they want to print? http://tc.eserver.org/35297.html http://tc.eserver.org/35297.html A Content Curator is someone who continually finds, groups, organizes and shares the best and most relevant content on a specific issue online. I think that professional writers and technical writers should consider a move towards this role. We already search for and find the best content, sift through loads of content, discard poor content, and publish the most worthy content whenever a software release goes out. This description also sounds like something a content strategist would do as part of their analysis of the content. http://tc.eserver.org/34907.html http://tc.eserver.org/34907.html オンラインコンテンツは、文脈とは無関係にユーザーの目にとまることが多い。本来想定された目的とは違う目的で読まれることもよくある。そうした目的を全部予測することはできないが、テキストのさまざまな利用を考慮することはできる。 http://tc.eserver.org/34573.html http://tc.eserver.org/34573.html Bullets definitely have their place in writing. But far too often, they're used to replace crisp, well-thought-out writing. http://tc.eserver.org/34489.html http://tc.eserver.org/34489.html It's hard to look at a page of text and try to decide where to divide things to create individual topics. That "bottom up" approach is kind of pointless, in fact. There are better ways. http://tc.eserver.org/34385.html http://tc.eserver.org/34385.html Citing the rise of graphic novels, comics, and in particular, Google’s new web browser Chrome, which has a comic-book-style manual, Opsteegh argues that technical communicators can learn a thing or two about conveying information from graphic novelists. http://tc.eserver.org/34295.html http://tc.eserver.org/34295.html Users often see online content out of context and read it with different goals than you envisioned. While you can't predict all such goals, you can plan for multiple uses of your text. http://tc.eserver.org/34265.html http://tc.eserver.org/34265.html Rather than spend hours coming up with a complex numbering scheme, this might be an excuse to implement something far more straightforward discovered by an extensive readability study at IBM, of which I was a part. My work involved sitting behind a one-way mirror with a stopwatch, watching people take tests that involved, among other things, "how fast can you find Figure 3-4?" We had cameras mounted over the participant's shoulders and could watch them thumb through the documents, and we also monitored eye movements. Then we followed up with a short interview where we got feedback. http://tc.eserver.org/34025.html http://tc.eserver.org/34025.html Technical writing has its mechanical aspects that need to be mastered. A good technical writer must know how to use English effectively as well as various software products to produce acceptable technical documents. But I wish technical writing were all about that. The hardest part comes before one even sits down in front of a computer to type the first word. The hardest part in documenting anything is organizing the information in a way that makes sense from the user’s point of view. Otherwise a technical document suddenly looks irrelevant. http://tc.eserver.org/33960.html http://tc.eserver.org/33960.html Using good sub-headers will help your users find the information they are looking for. It’s like navigation but without the clicking and the cool roll-over effects. http://tc.eserver.org/33822.html http://tc.eserver.org/33822.html Recent trends in XML content authoring demonstrate increasing shift towards advanced reuse patterns and multi-source compound document architectures. This imposes completely new requirements for the XML authoring tools, most of which were originally developed for narrative document authoring and architectures like Docbook or TEI. The key requirement is the ability to provide a single, transparent, directly editable view for such complex documents. http://tc.eserver.org/33673.html http://tc.eserver.org/33673.html Structured authoring isn't just for technical writers. Just about any department in an organization can benefit from it. This article looks at one way of bringing structured authoring to the masses: by adopting the authoring concepts used in an obscure word processor called Yeah Write. http://tc.eserver.org/33322.html http://tc.eserver.org/33322.html Book published by O'Reilly Media have a good flow to the information and they're well structured. One of the best features of many of those books is the introductory material. It can be a good guide, and help readers zero in on what they want to learn. http://tc.eserver.org/32188.html http://tc.eserver.org/32188.html This article defines the tasks and responsibilities for up to seven levels of information engineers, plus two levels of management. http://tc.eserver.org/30584.html http://tc.eserver.org/30584.html The inner sanctum of any good piece of writing is a solid, logical core. To produce the logical core, a writer frequently has to synthesize complex information, which means understanding it well enough to transform often muddled and random detail to clear and easy to apprehend expression. Synthesis of new information, being one of the most difficult thinking skills, can require more of a writer than the writer has time for. An editor's job, from the first draft to the last, is to help build the writing around an appropriate logical core. In this workshop, participants will practice techniques that editors can use to make sure that they find, or help the writer find, the core - what users need to know, and the order in which they need to know it. Participants will form groups to scan a document, using a checklist of tips to spot problems in the document's structure. Each group will report its findings to the larger group. http://tc.eserver.org/30503.html http://tc.eserver.org/30503.html Hypertext is a novel approach to computer-based information management based on associative indexing. The concept in general and the characteristics of typical systems are briefly reviewed. Strategies for applying hypertext techniques to the process of writing a technical document are examined. The way in which hypertext documents are used is discussed, focusing on a commonly encountered problem -- user disorientation within the document. Hypertext-based technical documents are compared and contrasted against their paper-based antecedents. http://tc.eserver.org/29977.html http://tc.eserver.org/29977.html This article looks at the impact of the introduction of semantic markup and structured authoring on the world of technical writers, editors, Help authors and content developers. This article is not specifically about the Semantic Web movement itself, but about the implementation of semantic concepts in the documentation field. http://tc.eserver.org/29395.html http://tc.eserver.org/29395.html The first time I heard of the STOP paper was sometime in the mid 80's when the historian of technical writing, John Brockman, phoned me to ask if my Information Mapping method of structured writing derived from the STOP method. At the time I told Brockman that there was no direct relationship between our two approaches since I'd never read the paper. When the editor of this journal sent me the STOP document in preparation for writing this paper, I read it with delight. Although our two innovations date from the same period, the STOP authors and I were working in two completely different disciplines, cultures, organizations, and locations. These two approaches resulted in modularity - albeit of quite different kinds. The main purpose of this project is to compare and contrast these two approaches to modularity. I should note here that I approach this article principally as an exercise in historical comparison, rather than as an exposition of my current views, about which I will say a bit at the end of this article. http://tc.eserver.org/29020.html http://tc.eserver.org/29020.html Work with structured abstracts--which contain sub-headings in a standard order--has suggested that such abstracts contain more information, are of a higher quality, and are easier to search and to read than are traditional abstracts. The aim of this article is to suggest that this work with structured abstracts can be extended to cover scientific articles as a whole. The article outlines a set of sub-headings--drawn from research on academic writing--that can be used to make the presentation of scientific papers easier to read and to write. Twenty published research papers are then analyzed in terms of these sub-headings. The analysis, with some reservations, supports the viability of this approach. http://tc.eserver.org/29151.html http://tc.eserver.org/29151.html There is little research on the use of titles in academic articles, and even less on different types of titles. In this article Crosby's taxonomy of titles [1] is brought up-to date and extended. Twelve types of titles are distinguished. The author argues that it would be helpful to discuss these different types with student writers. http://tc.eserver.org/28147.html http://tc.eserver.org/28147.html For a long time I have been an advocate of quality content on web sites. And now I am conducting an experiment that pitches quality content against immediate gratification. http://tc.eserver.org/28136.html http://tc.eserver.org/28136.html When users find the answers they are looking for, the investment in technical documentation gets a chance to pay off. In large volumes of technical information, just finding the answer can be half the battle. Microsoft found that users of its intranet were spending an average of 2.5 hours per day online - 50% of that being searching. This article was written as part of an experimental online workshop with the MITWA (Mentors, Indexers, Technical Writers & Associates) discussion group(http://groups.yahoo.com/group/MITWA/). The article retains the workshop format including learning assignments. http://tc.eserver.org/26063.html http://tc.eserver.org/26063.html Information Architecture (IA) as a discipline practiced by professionals in the information processing and development industry has many definitions and levels of understanding. http://tc.eserver.org/23756.html http://tc.eserver.org/23756.html Last month I stated this is not a place for jargon. I felt that was important enough to call out. I certainly am being called to task for that. http://tc.eserver.org/21517.html http://tc.eserver.org/21517.html When creating online and hardcopy information for software, technical writers tend to be prolific. Every piece of information is important, isn't it? And more information means happier users, right? Not every piece of information is necessary, however, and users don't want more information. Instead, they want the right information with easy access to it. This panel discussion describes why you, as a technical writer, need to reduce information and how you can reduce it by incorporating the following techniques and activities into the writing process. http://tc.eserver.org/20740.html http://tc.eserver.org/20740.html A technical writer develops a way to help a government contractor uncover procurement opportunities -- and in the process discovers a new opportunity for himself as an information profit center. http://tc.eserver.org/20547.html http://tc.eserver.org/20547.html Owens explains how technical writers can bolster their credentials as technically knowledgeable employees. He provides brief introductions to technologies that technical writers are most likely to encounter on the job: programming languages, databases, and Web server technologies. http://tc.eserver.org/14780.html http://tc.eserver.org/14780.html Tyson supports the claim of his title with a detailed discussion of three important benefits of XML. http://tc.eserver.org/14567.html http://tc.eserver.org/14567.html This course is designed to teach you to: recognize the variety and characteristics of styles of technical communication; adapt your writing style for different aims and audiences; revise efficiently and appropriately; and articulate reasons for revisions in your writing. http://tc.eserver.org/10279.html http://tc.eserver.org/10279.html The usefulness of concept mapping as a job performance aid for writers of technical documents was examined. Thirty-four writers were randomly assigned to one of two groups. The experimental group received 2 hours of training in the use of concept mapping. Both groups revised the same chapter from a computer manual, and an experienced technical editor blindly evaluated each revision. In part two of the study, revised texts were given to two groups of users. One group received a concept-mapped revision, while the other group received a text revised by a writer who had used conventional revision techniques. Readers' comprehension was tested and compared. Revision time was not significantly different between groups, and the editor's ratings of quality were not different. However, readers' comprehension was significantly higher with the concept-mapped versions. These results suggest that concept mapping is a useful revision tool for writers.