Design>Documentation>Information Design http://tc.eserver.org/dir/Design/Documentation/Information-Design A listing of the most recently indexed works about Design and Documentation and Information Design 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 Design>Documentation>Information Design http://tc.eserver.org/dir/Design/Documentation/Information-Design What Information Developers Can Learn from Software Developers http://tc.eserver.org/35677.html http://tc.eserver.org/35677.html 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? Structured Authoring and DITA http://tc.eserver.org/35435.html http://tc.eserver.org/35435.html What does structured authoring mean to you? Structured authoring is a publishing workflow that lets you define and enforce consistent organization of information in documents, whether printed or online. What it means to me: defining a goal and assembling architected topics to help the reader achieve that goal. Starting Points with Quick Reference Guides: Gathering Before Designing http://tc.eserver.org/34639.html http://tc.eserver.org/34639.html 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. Creating Topics: Where do you Draw the Line? 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. Modular Docs Part 1: Why You Want Modular, Topic-Oriented Documentation http://tc.eserver.org/34485.html http://tc.eserver.org/34485.html When documents are built from components, and the components can have contextual variations, it becomes possible to construct built-to-order documents "on the fly", 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. What Technical Communicators Can Learn from Comics 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. Wurman’s LATCH Model of Information Organization For Technical Documentation 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. The Changing Face of Technical Publications: Aberdeen Group's Topic-Based Authoring and Customization Strategy Guide http://tc.eserver.org/33424.html http://tc.eserver.org/33424.html Often conflicting pressures to produce communications that better fit customer demands as well as stay within tightening constraints on budgets and schedules are leading many technical communications organizations to a topic-based approach to authoring. In fact, 58% of participants in Aberdeen Group's October 2008 DITA and the Technical Communicator’s Transformation study report that they currently follow author content in a topic-based manner, with a vast majority of those remaining planning to implement one in the future. A topic-based approach promotes greater content reuse and is seeing a considerable impact on the authoring efficiency of technical communications projects today. The benefits of topic-based authoring can be compelling, with findings from the The Technical Communicator’s Transformation study indicating that when pursued the right way, topic-based authoring can have a broad range of benefits, enabling an organization to meet authoring and localization cost targets as well as documentation quality expectations, among others. However, as the adoption of this approach spreads, the advantages seen by today's leading organizations will flatten out. This Sector Insight provides a guide for current adoption of topic-based authoring and those still considering it; outlining the changes that are expected to take place in as topic-based authoring goes mainstream. Information Mapping http://tc.eserver.org/33338.html http://tc.eserver.org/33338.html 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. Structured Writing, Structured Documentation: What and Why? http://tc.eserver.org/32096.html http://tc.eserver.org/32096.html A brief comparison of two often-confused concepts. Doc or Die http://tc.eserver.org/31582.html http://tc.eserver.org/31582.html This blog discusses documents and information designs “in the wild" - especially those that are exceptionally good or exceptionally bad. Write Once, Use Many: Why and How We Make Product Information Modular http://tc.eserver.org/30622.html http://tc.eserver.org/30622.html 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. Question and Answer Method of Generating Manuals http://tc.eserver.org/30285.html http://tc.eserver.org/30285.html 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. A Millennial Paradigm for Documentation: the Scroll! http://tc.eserver.org/29444.html http://tc.eserver.org/29444.html 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. Exploring Information Design and Development http://tc.eserver.org/29375.html http://tc.eserver.org/29375.html Known to write a script or two to automate repetitive tasks like help builds, she also likes to write posts about XML-based information models like Darwin Information Typing Architecture (DITA). She often experiments with online help technology, enjoys writing blog entries, and wants to find new ways to use communication to help people understand technical solutions to complex problems. Keeping Pace with Change http://tc.eserver.org/28941.html http://tc.eserver.org/28941.html Documentation isn'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. Structured Authoring and XML: Part One http://tc.eserver.org/28185.html http://tc.eserver.org/28185.html 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. Structured Authoring and XML: Part Two http://tc.eserver.org/28186.html http://tc.eserver.org/28186.html 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. Structured Authoring and XML: Part Three http://tc.eserver.org/28177.html http://tc.eserver.org/28177.html 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. Enterprise Agility: SOX and Enterprise Information Integration http://tc.eserver.org/26733.html http://tc.eserver.org/26733.html 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. Building the Treasure House: Creating Knowledge Bases for the World Wide Web http://tc.eserver.org/26226.html http://tc.eserver.org/26226.html What is a knowledge base? What are the components necessary to build one? Documenting in N-Dimensional Space http://tc.eserver.org/25379.html http://tc.eserver.org/25379.html As technical communicators, we are being challenged with how to structure information in a multiple dimensional space made possible with Web technology. Visual Vocabulary Three Years Later: An Interview with Jesse James Garrett http://tc.eserver.org/23216.html http://tc.eserver.org/23216.html This interview focuses on Jesse James Garret's Visual Vocabulary, a site architecture documentation standard. Defining Information Architecture Deliverables http://tc.eserver.org/22466.html http://tc.eserver.org/22466.html One of the hottest topics these days in Information Architecture circles is documentation. This is probably partly because the IA's role is so ill defined. Our jobs sit perched between engineering and graphic design: go too far in one direction, we're doing the coding, go to far in the other and we are doing the design. Neither role maximizes the architect'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. XML and Documentation http://tc.eserver.org/21709.html http://tc.eserver.org/21709.html 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. Documenting Schemas http://tc.eserver.org/21657.html http://tc.eserver.org/21657.html The issue of documenting schemas—or any machine readable language—goes beyond simple additions of comments. Thereal challengeistocreateschemasthat arereadablebothdirectlybylookingat their sourcecodeandbydocumentation extraction tools. Information Planning for Successful Online Documentation http://tc.eserver.org/19781.html http://tc.eserver.org/19781.html Creating an information plan should be the first phase of any publication development life cycle, whether hard copy or online. The plan is a tool for reporting the results of your research about your audience, their tasks, the market, and the product. The plan presents the basic organization and content of the publications you intend to build, effectively directing the documentation team to produce a publication with very specific goals in mind. How the Process and Organization Can Help or Hinder Adding Value http://tc.eserver.org/19126.html http://tc.eserver.org/19126.html Do better information products result when technical communicators are well integrated into product development teams? Full Text Available Documentation, Participatory Citizenship, and the Web: the Potential of Open Systems http://tc.eserver.org/19057.html http://tc.eserver.org/19057.html Technical communicators have become increasingly interested in how to 'open up' 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. Developing an Information Strategy http://tc.eserver.org/18834.html http://tc.eserver.org/18834.html The role of the technical communicator has been changing dramatically over the past few years. Gone are the days when hefty user manuals are considered desirable. Technical communicators must now think of ways of building intuitiveness into products to obviate the need for reams and reams of hard copy documentation. This understanding forms the basis for developing an information strategy. Structuring Help for Re-Use http://tc.eserver.org/14559.html http://tc.eserver.org/14559.html Many teams are still laboring to transform poorly organized manuals into online help. But the biggest cllallege you face going from paper to online is not interface, but structure The better your structure, the easier your users will navigate. "Yes, But Does it Scale?": Practical Considerations for Database-Driven Information Systems http://tc.eserver.org/13946.html http://tc.eserver.org/13946.html This paper explores the process of designing and implementing a database-driven system of online documentation, and putting it live on the web for customers to use. Using real-life examples, it discusses practical considerations for balancing performance, scalability, and reliability. An Information Make-Over for Performance Centered Design http://tc.eserver.org/13271.html http://tc.eserver.org/13271.html Technical communicators have long harbored a secret that we are reluctant to admit to outsiders: Users don’t like reading manuals. They do it only as a last resort. Even online help systems, which we originally hoped would be easier to use, have not met with great enthusiasm among users. It’s an all-too-common dilemma – there is a lot of information that could be explained, but users struggle along as best they can without it. Part of the problem has always been that users are reluctant to leave their work to seek information -- and rightly so. They have work to do and deadlines to meet. Even if your manual or online help contains a wealth of useful information, it takes them away from their work and interrupts their train of thought. If they do try to use it, the help window typically overlays the interface and adds its own set of navigation, resizing, and searching issues. Retrieving Product Documentation Online http://tc.eserver.org/10264.html http://tc.eserver.org/10264.html As our high-technology clients become increasingly knowledgeable of the power of electronic media, we are confronted with questions on how the Internet and intranets can be used to deliver technical documents online. For example, one of our clients, a large international firm whose high-technology products are currently supported by printed literature, wants to be able to deliver their product documentation electronically, on customer demand. Their customers, typically professionals working in a fast-paced technical environment, need quick and easy access to appropriate technical information to configure our client's products.<P>In this article, we discuss how we came to answer our client's question: 'How can we make it easier for our customers to retrieve technical documents from our electronic library?' As we discuss below, we decided that searching online libraries could be facilitated by making the organization of the library conceptually apparent.