<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Document Design&gt;Information Design</title>	<link>http://tc.eserver.org/dir/Articles/Document-Design/Information-Design</link>
	<description>A listing of the most recently indexed works about Articles and Document Design and Information Design in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Document Design&gt;Information Design</title>
		<link>http://tc.eserver.org/dir/Articles/Document-Design/Information-Design</link>
	</image>
	<item>
		<title>What Information Developers Can Learn from Software Developers</title>
		<link>http://tc.eserver.org/35677.html</link>
		<guid>http://tc.eserver.org/35677.html</guid>
		<description>The shift in information development from a narrative to a modular writing style reflects the established shift towards modularization of source code. What can information developers learn from software developers? What are the challenges and benefits of the modular approach? </description>
	</item>
	<item>
		<title>Starting Points with Quick Reference Guides: Gathering Before Designing</title>
		<link>http://tc.eserver.org/34639.html</link>
		<guid>http://tc.eserver.org/34639.html</guid>
		<description>Dan Roam explains that drawing pictures can help you solve problems. He says the first rule is to “collect everything possible up front.” After collecting all your information, you then “lay it all out where you can look at it.” By laying out all the information, you can grasp the whole of it, make connections between various parts, see the important sections, and recognize patterns.</description>
	</item>
	<item>
		<title>Creating Topics: Where do you Draw the Line?</title>
		<link>http://tc.eserver.org/34489.html</link>
		<guid>http://tc.eserver.org/34489.html</guid>
		<description>It&apos;s hard to look at a page of text and try to decide where to divide things to create individual topics. That &quot;bottom up&quot; approach is kind of pointless, in fact. There are better ways.</description>
	</item>
	<item>
		<title>Modular Docs Part 1: Why You Want Modular, Topic-Oriented Documentation</title>
		<link>http://tc.eserver.org/34485.html</link>
		<guid>http://tc.eserver.org/34485.html</guid>
		<description>When documents are built from components, and the components can have contextual variations, it becomes possible to construct built-to-order documents &quot;on the fly&quot;, in response to user demands, rather than having to pre-create static versions of all possible variations. Once such a system is in place, it becomes possible for users to further customize the results by modifying the list of selected topics, rearranging their order, or even by adding new topics.</description>
	</item>
	<item>
		<title>What Technical Communicators Can Learn from Comics</title>
		<link>http://tc.eserver.org/34385.html</link>
		<guid>http://tc.eserver.org/34385.html</guid>
		<description>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.</description>
	</item>
	<item>
		<title>The Case for Simple Numbering</title>
		<link>http://tc.eserver.org/34265.html</link>
		<guid>http://tc.eserver.org/34265.html</guid>
		<description>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, &quot;how fast can you find Figure 3-4?&quot; We had cameras mounted over the participant&apos;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.</description>
	</item>
	<item>
		<title>Wurman’s LATCH Model of Information Organization For Technical Documentation</title>
		<link>http://tc.eserver.org/34025.html</link>
		<guid>http://tc.eserver.org/34025.html</guid>
		<description>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.&#xD;&#xD;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.&#xD;&#xD;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.</description>
	</item>
	<item>
		<title>An Approach to Visually Creating and Editing Nested Compound Document</title>
		<link>http://tc.eserver.org/33741.html</link>
		<guid>http://tc.eserver.org/33741.html</guid>
		<description>Currently, visual XML structured authoring applications can typically handle a small number of XML vocabularies. In some cases, they can even handle them in limited nested scenarios. One of the purposes of creating XML documents with compound vocabularies is to present related information on a given topic in different manners (tables, charts, etc).&#xD;&#xD;The synchronization of views between objects of different vocabularies in real-time editing helps authors realize this potential. In this presentation we will discuss an approach to visually creating, editing and synchronizing, nested compound XML vocabularies within one document. The open nature of the architecture enables developers to create plug-ins for new vocabularies including the ability to define synchronization. Also this architecture provides simple method to define visualization of a new vocabulary by utilizing plug-ins already developed and activated.</description>
	</item>
	<item>
		<title>Unstructured Documents in Structured FrameMaker</title>
		<link>http://tc.eserver.org/33522.html</link>
		<guid>http://tc.eserver.org/33522.html</guid>
		<description>A few days ago, there was a thread on the Framers mailing list regarding working in the structured FrameMaker environment. Someone commented that editing unstructured documents in the structured interface does not affect the unstructured documents. I found this to be untrue recently.</description>
	</item>
	<item>
		<title>Information Mapping</title>
		<link>http://tc.eserver.org/33338.html</link>
		<guid>http://tc.eserver.org/33338.html</guid>
		<description>Information Mapping is a proprietary method for the analysis, organisation, and presentation of information. It is based on the needs of the users and their purpose in using the documentation. Information Mapping has three parts: analysis, organisation, presentation.</description>
	</item>
	<item>
		<title>Building Up a Site Wireframe</title>
		<link>http://tc.eserver.org/32434.html</link>
		<guid>http://tc.eserver.org/32434.html</guid>
		<description>Every web designer should know and understand a Web site’s parameters before lifting a finger to start designing the site. In this article, you will learn the basics required to start designing business Web sites. While this information is useful if you want to build sites for others, it can also serve as a checklist article for sites you want to build for yourself.</description>
	</item>
	<item>
		<title>Structured Writing, Structured Documentation: What and Why?</title>
		<link>http://tc.eserver.org/32096.html</link>
		<guid>http://tc.eserver.org/32096.html</guid>
		<description>A brief comparison of two often-confused concepts.</description>
	</item>
	<item>
		<title>Write Once, Use Many: Why and How We Make Product Information Modular</title>
		<link>http://tc.eserver.org/30622.html</link>
		<guid>http://tc.eserver.org/30622.html</guid>
		<description>Faced with growing demand from customers for specific courses, addressing only their needs, in very short time-frames, we had to re-examine the way we worked. Patching together one-shot customized coursework was labor-intensive for a non-homogeneous and unsatisfactory result. Each new customer request required repetition of the same amount of effort. With reduced turnaround time and dwindling human resources, a solution had to be found.</description>
	</item>
	<item>
		<title>Using HTML as a Single Source Solution: A Case Study</title>
		<link>http://tc.eserver.org/29907.html</link>
		<guid>http://tc.eserver.org/29907.html</guid>
		<description>This paper presents an overview of the process and toolset developed for maintaining, updating, and generating user documentation for a complex Department of Defense (DoD) vulnerability analysis model. The roles of HyperText Markup Language (HTML) and eXtensible Markup Language (XML) in developing a single source solution are examined. The additional role of the Alchemy toolset, which is a customized solution to address page layout formatting in HTML, is also examined. Finally, practical application of this process/toolset to a generic software project is discussed.</description>
	</item>
	<item>
		<title>Question and Answer Method of Generating Manuals</title>
		<link>http://tc.eserver.org/30285.html</link>
		<guid>http://tc.eserver.org/30285.html</guid>
		<description>Several Texas Instruments writing groups are using a new manual publication method that emphasizes more customer interaction early in the manual development process. This emphasis brings project teams and customers together to accurately define their expectations for the documentation. Writers chunk information as they create the manuals, which allows reviewers to look at the small pieces one at a time and to focus only on those chunks containing information pertinent to their particular expertise. This method defines manual parameters early in the process, which simplifies usability testing.</description>
	</item>
	<item>
		<title>Combining the Print and Online Media Offers Synergies</title>
		<link>http://tc.eserver.org/29440.html</link>
		<guid>http://tc.eserver.org/29440.html</guid>
		<description>Companies had decades of experience in using printed materials to persuade readers to contact them, whether by phone, mail, or in person. This model of interaction with customers had worked so well and so predictably that we simply moved it online, largely unmodified. That was by no means wrong, but as Web technology and our comprehension of that technology both evolved, the approach proved limiting.</description>
	</item>
	<item>
		<title>A Millennial Paradigm for Documentation: the Scroll!</title>
		<link>http://tc.eserver.org/29444.html</link>
		<guid>http://tc.eserver.org/29444.html</guid>
		<description>Although some zealots have proposed eliminating printed information entirely in favor of online help systems, Adobe Acrobat files, and even e-books, discarding printed books may prove less effective than simply modernizing them. Scrolls are the logical successors to books.</description>
	</item>
	<item>
		<title>Explicit Structure in Print and On-Screen Documents</title>
		<link>http://tc.eserver.org/29236.html</link>
		<guid>http://tc.eserver.org/29236.html</guid>
		<description>The structure of print and on-screen documents is made explicit through headings and links. Three important concepts for understanding explicit structure are (1) the display-unit properties of each document medium, (2) the flexible relationship between explicit and implicit structure, and (3) the distinction between populated and unpopulated locations in a hierarchy. These concepts help us better understand standard print documents, structured writing, websites, help systems, and PowerPoint, as well as the potential effects of content management systems on how documents are created.</description>
	</item>
	<item>
		<title>Keeping Pace with Change</title>
		<link>http://tc.eserver.org/28941.html</link>
		<guid>http://tc.eserver.org/28941.html</guid>
		<description>Documentation isn&apos;t the most fun part of design and IA, but does it have to be the most painful? Samantha Bailey looks at a tool that may help.</description>
	</item>
	<item>
		<title>Structured Authoring and XML: Part One</title>
		<link>http://tc.eserver.org/28185.html</link>
		<guid>http://tc.eserver.org/28185.html</guid>
		<description>Implementing structured authoring with XML allows organizations to create better content. The addition of hierarchy and metadata to content improves reuse and content management. These benefits, however, must be weighed against the time and money required to implement a structured authoring approach. The business case is compelling for larger writing organizations; they will be the first to adopt structured authoring. Over time, improvements in available tools will reduce the cost of implementing structured authoring and make it affordable for smaller organizations.</description>
	</item>
	<item>
		<title>Structured Authoring and XML: Part Two</title>
		<link>http://tc.eserver.org/28186.html</link>
		<guid>http://tc.eserver.org/28186.html</guid>
		<description>In a structured authoring environment, authors create documents by assembling elements and text in an order permitted by the structure definition document. You might think of structured authoring as being similar to template-based authoring with a strict template. Authors do not assign formatting; the formatting is automatically assigned based on the structure of the document. Formatting may differ for different output media.</description>
	</item>
	<item>
		<title>Structured Authoring and XML: Part Three</title>
		<link>http://tc.eserver.org/28177.html</link>
		<guid>http://tc.eserver.org/28177.html</guid>
		<description>Not every content-creation group will benefit from structured authoring and XML. Sometimes, the expense of implementation outweighs the benefits realized, especially in smaller groups with less total page count.</description>
	</item>
	<item>
		<title>Enterprise Agility: SOX and Enterprise Information Integration</title>
		<link>http://tc.eserver.org/26733.html</link>
		<guid>http://tc.eserver.org/26733.html</guid>
		<description>The intent of Sarbanes-Oxley (SOX) can be characterized as risk reduction: reduce errors, inhibit fraud, and provide shareholders with transparent equal-access to material knowledge. But implementation is principally procedural controls and documentation, under threat of penalty. The vague parts of SOX are where the real leverage lies: principles of intent, and corporate transparency.</description>
	</item>
	<item>
		<title>Marrying Digital and Paper Documents</title>
		<link>http://tc.eserver.org/25838.html</link>
		<guid>http://tc.eserver.org/25838.html</guid>
		<description>The use of physical paper or digital files is not an either/or choice. The two are complementary. Currently, there are many examples of paper used as an interface to digital processes. The UPC found on items we buy and the barcoded labels on the packages we send are two prevalent examples. Many papers we use to reach our customers or to do our work within our organizations have at least one barcode.</description>
	</item>
	<item>
		<title>An Integrated Approach for a Model Based Document Production and Management</title>
		<link>http://tc.eserver.org/25622.html</link>
		<guid>http://tc.eserver.org/25622.html</guid>
		<description>The primary aim of the research presented in this paper is to provide pragmatic solutions to the problems of integrity and consistency of document based information, describing a building throughout its life cycle. The research demonstrates the computer-aided generation of project documents via a construction project data model. The first research activity involved the development of a Construction Project Reference Model (CPRM) and a Document Reference Model, from which various Applied Document Type Models can be derived. The work concentrated on the French Full Specification Document: the CCTP (Cahier des Clauses Techniques ParticuliÃ¨res), which is generated during the detail design stage. A generic Association Model was developed and used to index the CPRMâ€™s concepts to the CCTPâ€™s documentary elements supporting their description. Finally, the mechanisms enabling the generation of the project CCTP from the proposed structured reference CCTP are described.</description>
	</item>
	<item>
		<title>Documenting in N-Dimensional Space</title>
		<link>http://tc.eserver.org/25379.html</link>
		<guid>http://tc.eserver.org/25379.html</guid>
		<description>As technical communicators, we are being challenged with how to structure information in a multiple dimensional space made possible with Web technology.</description>
	</item>
	<item>
		<title>Defining Information Architecture Deliverables</title>
		<link>http://tc.eserver.org/22466.html</link>
		<guid>http://tc.eserver.org/22466.html</guid>
		<description>One of the hottest topics these days in Information Architecture circles is documentation. This is probably partly because the IA&apos;s role is so ill defined. Our jobs sit perched between engineering and graphic design: go too far in one direction, we&apos;re doing the coding, go to far in the other and we are doing the design. Neither role maximizes the architect&apos;s key skills; defining the organizational structure and behavior of the web site or application. An IA is most effective when they leave implementation and final graphic design out of the mix. The documents they create to express this have to be crafted with equal skill and diplomacy.</description>
	</item>
	<item>
		<title>XML and Documentation</title>
		<link>http://tc.eserver.org/21709.html</link>
		<guid>http://tc.eserver.org/21709.html</guid>
		<description>XML provides a robust, non-proprietary, and verifiable file format for the storage and transmission of text and data both on and off the Web. XML removes the complexity of SGML, making it easier to define your own document types, and to write programs to handle them.</description>
	</item>
	<item>
		<title>Documenting Schemas</title>
		<link>http://tc.eserver.org/21657.html</link>
		<guid>http://tc.eserver.org/21657.html</guid>
		<description>The issue of documenting schemas—or any machine readable language—goes beyond simple additions of comments. Thereal challengeistocreateschemasthat arereadablebothdirectlybylookingat their sourcecodeandbydocumentation extraction tools.</description>
	</item>
	<item>
		<title>Use Links Efficiently</title>
		<link>http://tc.eserver.org/20483.html</link>
		<guid>http://tc.eserver.org/20483.html</guid>
		<description>When you place content, Adobe® InDesign® 2.0 doesn&apos;t just add the graphics and text to your document—it keeps track of the original files as well. You can use the links to update the data if the original file changes, to track down missing graphic information, or to replace a graphic with another, without losing the transformations you&apos;ve applied. And when you work with text files, it&apos;s usually best to remove the link altogether.</description>
	</item>
	<item>
		<title>Information Planning for Successful Online Documentation</title>
		<link>http://tc.eserver.org/19781.html</link>
		<guid>http://tc.eserver.org/19781.html</guid>
		<description>Creating an information plan should be the first phase of any publication development life cycle,&#xD;whether hard copy or online. The plan is a tool for&#xD;reporting the results of your research about your&#xD;audience, their tasks, the market, and the product.&#xD;The plan presents the basic organization and content&#xD;of the publications you intend to build, effectively&#xD;directing the documentation team to produce a publication&#xD;with very specific goals in mind.</description>
	</item>
	<item>
		<title>Full Text Available Documentation, Participatory Citizenship, and the Web: the Potential of Open Systems</title>
		<link>http://tc.eserver.org/19057.html</link>
		<guid>http://tc.eserver.org/19057.html</guid>
		<description> Technical communicators have become increasingly interested in how to &apos;open up&apos; the documentation process - to encourage workers to participate in developing documentation that closely fits their needs. This goal has led technical communicators to engage in usability testing, user-centered design approaches, and, more recently, open source documentation. Although these approaches have all had some success, there are other ways to encourage the participatory citizenship that is implied in these approaches. One way is through an open systems approach in which workers can consensually modify a given system and add their own contributions to the system. </description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Document-Design/Information-Design.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>