http://tc.eserver.org/dir/Presentations/Documentation A listing of the most recently indexed works about Presentations 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/Presentations/Documentation http://tc.eserver.org/35802.html http://tc.eserver.org/35802.html One of Flare’s shortcomings is the inability to easily embed video files. However, if you use the Camtasia Studio’s Express Show format as your video format (and you choose the SWF option), you can insert the video into Flare by inserting the video as if it were a picture. Here’s a two-minute screencast showing the processing for inserting a video into Flare. You can also put the video in a drop-down hotspot. http://tc.eserver.org/35468.html http://tc.eserver.org/35468.html Are we giving users the help they need, in the way they need it? Go minimal. 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. http://tc.eserver.org/35436.html http://tc.eserver.org/35436.html This a short video overview of managing a documentation project. It's something we put together as a test of some of the functionality of Techsmith's Camtasia software. http://tc.eserver.org/35322.html http://tc.eserver.org/35322.html What Are These Tools? Screen recorders that let you: record a series of screens as frames in a movie – like chaining together screen shots; annotate the frames with text captions, high-lights, and other effects for enhanced learning and explanation; add testing – informally through “dead-end” quizzes or formally using eLearning; publish the result. http://tc.eserver.org/35334.html http://tc.eserver.org/35334.html In the US today, there are 82.5 Million Content Creators 13.9% create content in virtual worlds 18.1% create video content 23.9% create blog content 79.7% create content on a social network. All we need is a standard that will support the topic- based nature of “how to” video content XML, and by extension, DITA, seemed to be a perfect fit. http://tc.eserver.org/35338.html http://tc.eserver.org/35338.html Web 2.0 includes: wikis, podcasts, blogs, widgets/gadgets, social networks … and combinations of all the above. Not everyone contributes equally – Creators (18%), Critics (25%), Spectators (48%). But all are important. http://tc.eserver.org/35108.html http://tc.eserver.org/35108.html The notes for a presentation (titled Thinking Outside the Book: Wikis for Writing and Delivering Documentation, that discusses the whys, the tools, and the techniques of using wikis for documentation. http://tc.eserver.org/34861.html http://tc.eserver.org/34861.html In open source, the standards for documentation are typically quite low. But they don't have to be. http://tc.eserver.org/34610.html http://tc.eserver.org/34610.html Changing how we write, manage, and publish; how we relate to management and customers, and do business. http://tc.eserver.org/34420.html http://tc.eserver.org/34420.html Online formats can be confusing—consider "WebHelp" vs. "Web Help." This session describes XML, XHTML, HTML Help, WebHelp, DotNet Help, AIR, and others—and how to select the appropriate one. http://tc.eserver.org/34063.html http://tc.eserver.org/34063.html Online help. User assistance. That thing that pops up when you press F1. No matter what you call it, user assistance is an important element in the experience of a user. It can mean the difference between a frustrated user and a productive one. But is today's user assistance all it can be? Are we giving users purposeful information at the right time, in the most effective format, and ultimately in the way that they need it? Unfortunately, no. http://tc.eserver.org/33731.html http://tc.eserver.org/33731.html DITA is natural. Do XML/DITA conversion research now. Wiki is especially good for iterative writing. Structured wiki authoring in coming. http://tc.eserver.org/32683.html http://tc.eserver.org/32683.html If you know API writing, there is greater demand for your skills, that is, there are more jobs to which you can apply. At the same time, there is a shortage of API writers. API writers tend to work more closely with development, instead of through product management or product definition or through specs. You are closer to those who design the product, privy to design decisions -- closer to the action. http://tc.eserver.org/31973.html http://tc.eserver.org/31973.html Discusses in detail why you might want to consider a specific tool for help authoring. http://tc.eserver.org/29535.html http://tc.eserver.org/29535.html An overview of web design methods, including a survey of questions one should ask during the process. http://tc.eserver.org/29526.html http://tc.eserver.org/29526.html Describes how project management can help technical communication professionals better plan and manage their technical documentation projects. http://tc.eserver.org/28794.html http://tc.eserver.org/28794.html Mike Hamilton from Madcap Software visited the Suncoast chapter in Tampa, Florida, and presented on Flare. In this presentation, he talks about the story behind RoboHelp and Macromedia/Adobe (this blew my mind). He also provides a lot of inside detail on Flare. http://tc.eserver.org/28749.html http://tc.eserver.org/28749.html This is a presentation titled 'Creating Help in the Web 2.0 Age' that Neil Perlin gave to the Suncoast Chapter in Tampa, Florida in February 2007. Neil talks about what Web 2.0 is, and how help can be delivered on the fly according to specific user requests. http://tc.eserver.org/28750.html http://tc.eserver.org/28750.html To tame the API beast, a successful description must: be accurate and complete (of course); take the perspective of the programmer who's going to use the class. http://tc.eserver.org/28754.html http://tc.eserver.org/28754.html In this podcast, Katriel Reichman, a technical writer at Method M in Jerusalem, Israel, talks in-depth about how to use wikis for documentation. http://tc.eserver.org/28491.html http://tc.eserver.org/28491.html This PowerPoint tutorial is just what you need to get up to speed using PowerPoint to create engaging and effective presentations. Whether you're creating a presentation for an informal gathering, a school or classroom assignment, or one for your business partners or associates, PowerPoint is a powerful tool that will help get the job done. Each PowerPoint tutorial features text and screen shots, and some include narrated multimedia tutorials in Flash. http://tc.eserver.org/26991.html http://tc.eserver.org/26991.html Information about how to use the Canon Elura 50 camcorders for technical communication multimedia. http://tc.eserver.org/26307.html http://tc.eserver.org/26307.html A set of slides that gives a brief introduction to DocBook and why it is useful for technical writers. Also available in PDF format. http://tc.eserver.org/26222.html http://tc.eserver.org/26222.html Developing a process and using guidelines for editing online documents, both rooted in traditional editing practices. http://tc.eserver.org/26225.html http://tc.eserver.org/26225.html As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done? 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? http://tc.eserver.org/26214.html http://tc.eserver.org/26214.html Marketing documentation entices clients to buy your products. Technical documentation tells clients how to use your products. http://tc.eserver.org/26205.html http://tc.eserver.org/26205.html This presentation focuses on creating video demonstrations of software for online tutorials, using AVI files, and Inserting these files into Windows Help or HTML. http://tc.eserver.org/26204.html http://tc.eserver.org/26204.html Common goofs, mistakes, bloopers, mal mots, slip ups, lapses, oversights, gaffes, and 'foe paws' in online documentation and Help. http://tc.eserver.org/26194.html http://tc.eserver.org/26194.html Structured documentation is semantic, rather than presentational. Components have identifiable structure. HTML and Word are somewhat structured. DocBook is strictly structured. http://tc.eserver.org/25833.html http://tc.eserver.org/25833.html A presentation about techniques one could employ using AuthorIT. http://tc.eserver.org/23167.html http://tc.eserver.org/23167.html Identify the user. Identify the user's goals. Drill down to task level. Establish what the user knows. Identify what the user needs to know. Identify what the user should NOT know. http://tc.eserver.org/21696.html http://tc.eserver.org/21696.html Experienced programmers find the man pages very useful but a naive user often finds them overwhelming. http://tc.eserver.org/19754.html http://tc.eserver.org/19754.html Problems with the current paradigm. - Difficult to write and hard to use. - Inconsistent between project revisions. - No assurance that effort will pay off for end users. - Not designed to provide high quality responses to queries. http://tc.eserver.org/18795.html http://tc.eserver.org/18795.html A presentation describing techniques for Adobe FrameMaker and WebWorks Publisher users. http://tc.eserver.org/18279.html http://tc.eserver.org/18279.html Style guides present a series of rules for standardizing writing. Style guide developers run the risk of concentrating too much on these rules, and too little on other factors that may ultimately affect the quality of the documents that are governed by the style guide. I would like to consider some of these other factors in this paper. I’ve drawn this discussion from Battelle’s efforts developing style guides in various industries. Another reason to involve your clients in the development process is to help ensure that the style guide includes the information they will need. For example, we included tips on using Microsoft Word in a style guide that would be used by writers working in Word. Don’t be afraid to be creative when deciding what to include in your style guide; if it gives writers a reason to look something up in the style guide, http://tc.eserver.org/18257.html http://tc.eserver.org/18257.html Online tools can improve documentation management in several ways, depending on management goals of cost, schedule, or quality. Cost management tools need integration with automated status and quality assessment tools. Workflow simulation tools show great promise for avoiding bottlenecks in the document development process. Automated tools can enforce quality checkpoints and provide model document templates. The continual evolution of online documents will require new management approaches and goals. http://tc.eserver.org/18253.html http://tc.eserver.org/18253.html While technical writing is becoming a more obvious part of undergraduate education, it is not uncommon for an engineer to face the task of writing documentation without much training in the craft of communication. Other members of production teams may have received even less training, and yet have an equal or greater need to have a say in how documentation is produced and what it contains. In this paper, we will examine a situation in which an assembly worker, or system integrator, demanded the opportunity to document the appropriate ways to assemble complex Test and Measurement systems (for evaluating the electronic components of products such as PC’s, cars, and cellular phones), and the effects her change in roles has had on the production processes for both systems and their documentation. http://tc.eserver.org/18225.html http://tc.eserver.org/18225.html Designing multi-platform online help can be made more efficient by placing special effort in the design of the development plan. If the development plan is broken up into four key elements the resulting multi-platform design will yield a great amount of latitude for both maintenance and future enhancements. During the demonstration we will discuss our use of these elements to design both online and hardcopy documentation to support both a mainframe and a windows interface. http://tc.eserver.org/18219.html http://tc.eserver.org/18219.html With the explosion of online help authoring tools (primarily in the Windows® environment) companies are clamoring for the ability to produce online help on multiple platforms. This demonstration presents one solution to the problem of creating online help in a multiplatform environment. We will demonstrate the process of translating FrameMaker™ files from the Macintosh® to Windows NT®, and ultimately, to UNIX®. http://tc.eserver.org/18216.html http://tc.eserver.org/18216.html In written instructions, the sequential order of procedural steps is crucial for effective and efficient performance. In this paper we demonstrate several “rules” for optimizing instructions in this respect: First things first: put instructions in an order that prevents users from neglecting important steps. Minimize cognitive load: put instructions in an order that allows readers to forget what they read. Save time and effort: put instructions in an order that “on average” requires as little time as possible of the readers. http://tc.eserver.org/14557.html http://tc.eserver.org/14557.html To address the increasing need for online delivery of customizable documentation, a writer for an information warehouse product presented, developed, and delivered an online documentation user interface. Developed using the standard PC development tools for the application, including Visual Basic and Access, this system lets users view and customize Word documents, online help files, and Access database tables. http://tc.eserver.org/14558.html http://tc.eserver.org/14558.html It’s sometimes difficult to determine which tool is right for a particular job. This demonstration shows the types of online documentation projects that are best suited to each of three online authoring tools: Dot-To-Help by WexTech Systems, ToolBook by Asymetrix, and RoboHelp by Blue Sky Software. Technical writers who have used these products to create online help projects will discuss feature comparisons, system requirements for both author and user of the online documentation, and limitations of the tools. By seeing demonstrations of the authoring tools and the projects created with these tools, attendees should have a better understanding of what each tool can help them accomplish. http://tc.eserver.org/14560.html http://tc.eserver.org/14560.html Traditionally, custom document production begins with an empty “New” electronic document and with the writer confined to the paper delivery mode. Networked software reuse facilities can allow writers to avoid this requirement of continually starting from scratch. Hence, net worked software reuse may provide a framework for efficiently creating custom documents in either academic or industrial settings for single-source, multimode delivery (Reece, 1993- 1994). More importantly, software reuse facilities may also provide common ground for technical training within a variety of computing environments. This paper defines software reuse, recommends a process for the development of documents in a software reuse facility, and provides information on quality characteristics for evaluating such software. 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. http://tc.eserver.org/14541.html http://tc.eserver.org/14541.html Working in close cooperation with the chief subject-matter expert (SME) for a major group of documents, we changed the document development process. Instead of having a SME write a draft-leaving the technical writer function as secretary, editor, and layIout technician—we involved the writer from the beginning of the project. The result was a cleaner, neater document development process; a better document; and a lot less trouble for all concerned. http://tc.eserver.org/14522.html http://tc.eserver.org/14522.html Defining the quality of information has long been a controversial item. Many different theories and methodologies have been brought forward; almost all share at least one common basis— Typographical errors lower the perceived quality of information. In this experiment, the first of a planned, series, we examined the effects of typographical on the user’s perception of the quality of the product and documentation. The conclusions of this first study, and the implications we can make draw them, are presented in this paper. http://tc.eserver.org/14520.html http://tc.eserver.org/14520.html It would be useful to determine how much effect errors in product documentation have on users, if errors do not seriously interfere with product use. In an effort to start collecting information on this issue, we designed an experiment to explore the reactions of users to a simple interactive program with flawed documentation. We hypothesized that the product quality would be judged in part by the quality of the documentation, if the errors in the documentation interfered with task performance. We also hypothesized that some but not all users would be sensitive to documentation errors and would downgrade their rating of the program and the documentation based on these errors. The results of our experiment are presented in this paper. http://tc.eserver.org/14521.html http://tc.eserver.org/14521.html Clear, positive feedback can contribute significantly toward improving the quality of printed and on-line documentation. Wizen feedback is negative, unclear, or incomplete, however, the accuracy and quality of a document can suffer, and misunderstandings between colleagues can result. Those who are responsible for reviewing documental ion can enhance that process by knowing what type of feedback to provide and how to offer it in a clear and constructive way. Those who request feedback on their documentation projects also can enhance the review process by clearly identifying the project scope and specifying their evaluation needs to their reviewers. http://tc.eserver.org/14527.html http://tc.eserver.org/14527.html The writers at Software Publishing Corporation faced the challenge of reducing the page count of their manuals by more than 50%—without sacrificing quality, extending the schedule, or starting from scratch! They found that approaching this daunting task from several different directions at the same time proved to be the most effective. While the following tips apply primarily to DOS and Windows software manuals, the tips are a good starting point for streamlining any documentation set. The benefits include cutting dollars from the per unit cost of goods and promoting greater customer acceptance of documentation as a learning tool. http://tc.eserver.org/14550.html http://tc.eserver.org/14550.html Online documentation is now widely accepted for its convenience and cost savings. However, some small, non-Windows shops find very few offerings in the market place for online documentation software. http://tc.eserver.org/14503.html http://tc.eserver.org/14503.html According to the SCANS report, '80 percent of the workers on whom American employers will depend as we enter the 21st century are already on the job.' Onsite employee training and retraining must become a major focus for American companies. Technical communicators can develop site-specific training materials for their employers, but they will need to 'speak another language' in order to communicate the potential savings and benefits to management. Technical communicators who produce site-specific training materials can increase their job security by increasing their employer's ability to compete. http://tc.eserver.org/14516.html http://tc.eserver.org/14516.html Developing a methodology for creating user documentation involves the following phases: analyze need, plan, define requirements, design, construct, test, implement, and maintain. In addition to moving through these phases while creating the methodology, you must include each of these standard phases as a major section in the methodology. This paper describes how the Documentation and Training Center of Excellence used the standard project methodology phases to create and implement a methodology which tied closely to the phases. http://tc.eserver.org/14548.html http://tc.eserver.org/14548.html Aha, you say, you’ve finally gotten permission to go online. And your boss has even allocated enough precious-budget dollars to buy the right hardware and software to do the job. How hard can if be to find a good authoring tool, you think. And then you start to receive the product literature from n developers of Windows help authoring tools . . . http://tc.eserver.org/14536.html http://tc.eserver.org/14536.html Writers working on the UNIX® operating system can use basic utilities, along with shell programming, to write scripts that check documentation for completeness and adherence to house style. http://tc.eserver.org/14551.html http://tc.eserver.org/14551.html One way to create Windows help is by using Word for Windows. To begin, you must become familiar with the help concepts of topics and hyperlinks. Then, you create these components: projectile, header file, and source files. Source files are created using Word for Windows. Next create the actual help file by compiling the elements you have created. Finally, view and debug the results. http://tc.eserver.org/14404.html http://tc.eserver.org/14404.html Want to create a colorful, interactive online version of your FrameMaker® documents? Not many steps are involved in making the conversion: start with template changes in the FrameMaker files; create a postscript file; convert it into a PDF (Portable Document Format) file using Adobe Distiller®; and add final touches to the PDF file in Adobe Exchange®. http://tc.eserver.org/14377.html http://tc.eserver.org/14377.html Animated demonstrations are replacing text as the vehicle for documentation, help, and training on new software systems. An animated demonstration is a demonstration of a particular feature or features by a ghost user. The demonstration executes the procedure for performing a task, on-screen, as the user passively watches. Whereas research into the effectiveness of animated demonstrations has produced mixed results, certain patterns of behavior are emerging. The current study replicates the learning advantage offered by animated demonstration and shows that retention is equal to that of a group instructed by text after a one week retention interval. Implications for development of on-line training materials are discussed. http://tc.eserver.org/14378.html http://tc.eserver.org/14378.html Help systems have become an important part of the Technical Communicator’s repertoire. If we as communicators approach developing help systems in the same way we approach writing paper documentation, we miss the advantages of using software development methodology. http://tc.eserver.org/14388.html http://tc.eserver.org/14388.html SGML (Standard Generalized Markup Language) became an ISO-approved standard and was adopted as a Japanese Industrial Standards. Recently, SGML has begun to be used more widely in Japan. We, the Corporate Design Center of Ricoh Company, Ltd., have completed development of the a single SGML module DTD (Document Type Definition), customization of a SGML editor, and the implementation of review system using the world wide web. In addition, we have developed an automatic DTP system based on SGML. http://tc.eserver.org/14366.html http://tc.eserver.org/14366.html Developing a Windows online help system that clients can use effectively and bringing it in on time and within budget is a challenging task. You can dramatically improve your chances of success by doing the following: Develop help as sofnvae is being developed (and even before!); Chunk information for easy reading and to facilitate reuse by other writers; Create design and style guidelines to cut down peer review and editing time; Develop and use information webs to cut down on technical review time; Integrate the information web and the user interface to complete your help system. http://tc.eserver.org/14375.html http://tc.eserver.org/14375.html The concept of the “paperless oflce” has become popular with executives who want to reduce costs and users who, often with good reason, refuse to open a manual. Technical communicators, who often understand the practical flaws behind this concept, must be prepared to make smart decisions about what information to present in manuals and what to present online. They must also justljj to management their decisions either to resist moving everything online or tofkd creative ways to do so without forgetting about the needs of the user. http://tc.eserver.org/14373.html http://tc.eserver.org/14373.html You need not be a programmer to begin producing effective, attractive HTML Help or Webpages. You can use pubiished tempiates andauthonng toois and study an existing page’s HTML code to heb you produce pages whiie you learn. Templates allow you to add your content to existing skeleton pages. You can also use an HTML or HTML Heip authoring tooi to create your help. HTML Heip authoring tools aiiow you to add WinHeip-like functionality and ~eamnce to your HTML Hefppages. Using your browser and a text editoc you can study HTML code frum an existing Webpage. Using these methods, you can learn HTML while already producing effective Heip. http://tc.eserver.org/14372.html http://tc.eserver.org/14372.html In preparation for the next release of our flagship so~are product, the International Publications Department at Waters Corporation wanted to assess the usefulness of our current product software documentation with the idea of moving the next generation of documentation in the direction requested by our customers. Based on extensive customer contact, we formulated a plan to dramatically revamp the documentation, namely to replace the paper user’s guides and transform our existing online Help into a comprehensive Online User’s Guide. http://tc.eserver.org/14351.html http://tc.eserver.org/14351.html To successfully communicate to users, documentation must do more than meet the user’s information needs, it must present the information in the same way the user processes the information. The design of sofhYare and its accompanying documentation must be reconceived so that the design is done porn the problem-solver’s pornt of view. Effectively designing documentation requires the writer to: start with the user, answer the user’s rest questions, optimize all documentation as a smgle umt, allowfor user mistakes, and consider how you present the information. http://tc.eserver.org/14347.html http://tc.eserver.org/14347.html This panel will review the existing literature on how we mentally process online documentation and describe some implications for effective online document design. We invite the audience to define with us some critical areas for further research. http://tc.eserver.org/14376.html http://tc.eserver.org/14376.html As online help has evolved from simple field descriptions to a fully capable hypertext medium designers of software documentation have been faced with determining the best mix of paper and online. Which information goes in which medium? How much, if any, should be repeated in both? This paper describes two case studies in which hcumentation teams addressed these issues while redesigning their information sets. By the end of both projects, the documentation was streamlined redundancy between pn”ntand online was reduce4 and the majority of the information was presented online. http://tc.eserver.org/14354.html http://tc.eserver.org/14354.html This workshop presents an introduction to use cases - a planning tool which can be used for capturing a future documentation system's functional requirements as well as the overall information requirements of end users. You learn what a use case is and what recommended guidelines there are for creating use cases. You also learn how use cases are applied in the documentation development process as a whole. http://tc.eserver.org/14352.html http://tc.eserver.org/14352.html One of the ironic things about online help systems is that they are very often not helpful and even increase the user's frustration and stress level. A consequence of this increased frustration sometimes results in the rejection of the software. One solution is to increase the effectiveness of online help systems by designing them from an instructional design perspective. Some of the things we can provide users include: imperative, task-focused procedures; graphic feedback; access to redundant instructions; links to tutorial practice; philosophical and conceptual explanations for “why” they are completing specific tasks. http://tc.eserver.org/13961.html http://tc.eserver.org/13961.html Traditionally, technical editors have ensured consistency in the voice, grammar, and terminology of print documentation. As publications departments have moved to delivering online documentation, the role of the editor has varied and expanded. Editing multimedia documentation requires an even wider scope of skills than editing online documentation. http://tc.eserver.org/13942.html http://tc.eserver.org/13942.html The old school of software interface design and document writing took the view that if the user could find the information someplace, the user could use it. But simply sticking in details ignores how readers access and process information. 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. http://tc.eserver.org/13689.html http://tc.eserver.org/13689.html Creating award-winning computer servicing documentation involves knowing something about customer service engineers, what content to provide, what kinds of art work best in different contexts, and differences in producing hard copy vs. online documentation. If you want to move from writing software or marketing documentation, find a good mentor to help you gain experience with these elements. http://tc.eserver.org/13683.html http://tc.eserver.org/13683.html Our methodology for knowledge base authoring guides you through step-by-step examples of how to create and maintain knowledge bases in a database. The methodology allows your team to develop simple solutions for information requests as well as sophisticated diagnostic trees for troubleshooting. With the information stored in a database, you are able to easily access the information and use it for a variety of projects. http://tc.eserver.org/13682.html http://tc.eserver.org/13682.html The need for a more comprehensive documentation development process at Computerized Medical Systems, Inc. (CMS) was identified in an annual year-end review meeting of the CMS User Documentation Section. The goal was set to develop and implement such a process. A key component would be a set of comprehensive Content Specification Guidelines. Initial research consisted of reviewing existing literature and compiling a list of information considered essential to effectively plan a documentation project at CMS, based on discussion with software developers and technical communicators as well as experience gained from previous projects. The new process was implemented and has provided benefits throughout the company. http://tc.eserver.org/13480.html http://tc.eserver.org/13480.html This paper defines a good manual to have a good balance in quality, cost (close to estimation, not over), and delivery (on time schedule). Analyzing our past problems, we have been developing documentation process to control these three factors through the following: working as a team, standardizing an estimation method, and standardizing an evaluation system. http://tc.eserver.org/13462.html http://tc.eserver.org/13462.html In a corporate procedures writing program staff members of a financial company wrote procedures documenting their everyday work. Because these staff members were not trained in technical writing, a twostage training process was developed. The writing would be done by the in-house staff; in this case, financial analysts and accountants, referred to as SME writers. These staff members were required to document their everyday functions but had no professional training in writing; training, therefore, was a prerequisite to ensuring a successful writing program. http://tc.eserver.org/13457.html http://tc.eserver.org/13457.html To learn software, passive users prefer to have concepts and procedures clearly spelled out for them, while active learners prefer experimenting with the program. When designing a manual, writers should keep both types of users in mind. Writers at WordPerfect are currently experimenting with minimalist design models that encourage active learning. One such model is an “On Your Own” section which guides users through creating a document. Another model is a visually oriented “Applications” section which provides tips on how to create a document. http://tc.eserver.org/13392.html http://tc.eserver.org/13392.html This paper discusses the software development process at a particular government agency, the documentation standards used by that agency, the problems caused by these standards, and some of the solutions that have helped the technical communication there to work through the problems and still create documents of use to the reader. http://tc.eserver.org/13305.html http://tc.eserver.org/13305.html How do you create ERP documentation for your end users? One key is to map the five phases of the ERP documentation creation process to the phases of an ERP system implementation. Phase 1 is primarily for analysis, phase 2 is for the design process, and phase 3 consists of the actual building of the documentation. During phase 4, you should finalize all building and testing of the system. During phase 5, you should research end user trouble spots and continually improve the documentation in those areas. http://tc.eserver.org/13301.html http://tc.eserver.org/13301.html Computerized Medical Systems, Inc. (CMS) has implemented an extensive online help system based on HTML for its FOCUS radiation therapy planning system. Netscape Navigator was selected as the browser because FOCUS is based on the UNIX platform and Netscape was the only HTML browser available for UNIX. http://tc.eserver.org/13300.html http://tc.eserver.org/13300.html People often have to create documents for different audiences and for different media, (e.g. web, Help, training). However, timelines and budgets for developing information are often tight. This means we have to find more efficient ways to develop information. One way is to consider single sourcing information for multiple users and media. While single sourcing does take more up-front planning, it can significantly decrease costs and development times once implemented. http://tc.eserver.org/13298.html http://tc.eserver.org/13298.html The policies and procedures (P&P) developer must address more than format and style issues in designing policies and procedures information. There are at least five levels of design for policies and procedures information. Level 1 concerns the architecture in which the information resides. Level 2 concerns the type of relationship that exists among documents within the architecture. Level 3 concerns the approach used in designing and developing the information content within a policies and procedures document. Level 4 concerns the writing methods to use. Level 5 concerns the various writing techniques for presenting information in units individually and collectively within a policies and procedures document. http://tc.eserver.org/13297.html http://tc.eserver.org/13297.html The responsive hypermanual is a new method of delivering documentation that orders the contents of an online manual in response to the user’s current task. It uses hypertext modules controlled by an SQL database for managing the development, and presentation of modular documentation to provide a uniquely usercentric system. their needs. When the user asks technical support for help, they delegate the effort of assembling material scattered throughout the document into a meaningful answer. http://tc.eserver.org/13295.html http://tc.eserver.org/13295.html Working in a regulated environment (for example, an ISO-certified company or a company regulated by the FDA) necessarily changes the way documentation is developed and managed. The documentation development process must exist and must meet all of the requirements set by the governing body, yet not be so mired in detail that it overwhelms the writers and managers. http://tc.eserver.org/13289.html http://tc.eserver.org/13289.html This paper describes the end-to-end approach we used to create and validate scenario-driven information for a new product. This approach focuses as much on designing and testing information as it does on writing the information. http://tc.eserver.org/13284.html http://tc.eserver.org/13284.html TimeCorp, a leading publisher of commercial labor management software, has been working to incorporate increased levels of user support within its software interface. In this case study we will present samples of the TimeCorp product support as it evolved over time, from the initial online help to the electronic performance support (EPSS) prototype to the performance-centered design (PCD) solution. The types of information provided in the support also evolved to match the mode of presentation. The documentation team led this evolution within the organization and their roles have changed as a result. 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. http://tc.eserver.org/13254.html http://tc.eserver.org/13254.html While implementing a Modular Documentation Method and the development of Responsive Hypermanuals (Lettvin, 1999), concerns were raised as to how to effectively manage the potential explosion of seemingly fractured document components (modules) while maintaining key infrastructure and quality assurance mechanism already in place. This paper examines one unique solution to this problem: building a web-based database application that manages and tracks modules, documents and resources for any documentation project. In addition, it has a built-in structure for handling a robust documentation process. Some advantages and obstacles in developing a modular documentation database solution for the web are discussed. http://tc.eserver.org/13215.html http://tc.eserver.org/13215.html Starting and Maintaining a Documentation Department – Concepts, Principles and Techniques” includes information about assessing business needs, establishing credibility, building the department, understanding the product life cycle and development practices, and successfully maintaining a documentation department. It includes innovative, creative, and original management concepts, tasks, principles, techniques for newly promoted managers, managers new to a company, and for seasoned managers to ensure success or continued success managing documentation departments. http://tc.eserver.org/13211.html http://tc.eserver.org/13211.html Most customers do not provide direct feedback on product documentation. Instead, when documentation fails to provide the information that a customer needs to use a tool effectively, he or she calls Customer Support for advice. To find out what information was missing or incorrect in our product documentation, I analyzed the Cadence Customer Support call logs that pertained to my products to find out what questions customers ask most about each product. I then partnered with teams of applications engineers (AEs) to improve our documentation by answering common questions, both on the Web in FAQ documents and in product manuals. http://tc.eserver.org/13186.html http://tc.eserver.org/13186.html PDAs raise new opportunities for technical communicators to provide corporate information in a compact, electronic package. http://tc.eserver.org/13202.html http://tc.eserver.org/13202.html HTML...HTML Help...HTML-based help...WebHelp... JavaHelp...Oracle Help...what does it all mean? There are so many online help options, it’s easy to get overwhelmed and confused. This paper discusses the difference between HTML Help, WebHelp, JavaHelp, and Oracle Help. Specifically, it explains each help technology’s features and limitations, the user requirements, and best use. http://tc.eserver.org/13174.html http://tc.eserver.org/13174.html The need for a more comprehensive documentation development process at Computerized Medical Systems, Inc. (CMS) was identified in an annual year-end review meeting of the CMS User Documentation section. The goal was set to develop and implement such a process. A key component would be a set of comprehensive Content Specification Guidelines. Initial research consisted of reviewing existing literature and compiling a list of information considered essential to effectively plan a documentation project at CMS, based on discussion with software developers and technical communicators as well as experience gained from previous projects. The new process has been in place for about two years and has provided numerous benefits to the company, though some challenges remain. Process (4) that concentrated on the document specification component of the CMS process. http://tc.eserver.org/13169.html http://tc.eserver.org/13169.html Users reach for job aids for a range of reasons, from recalling the highlights of a task, to finding codes that are used infrequently. The compact size offers safe harbor after working through a detailed user’s manual. Creating a job aid, however, is quite time-consuming. You must select the content, then concisely and elegantly incorporate key tasks and codes. Finally, you need to produce the job aid in a functional format. The hardest task of all is to sell job aids to management. You need to sell productivity and results, not size. After all, good things come in small packages. http://tc.eserver.org/13151.html http://tc.eserver.org/13151.html We use an Excel workbook to record information about the documents we produce. Originally created to assign document order numbers, we have added to it many categories of process data. It now provides valuable management and tracking information. More importantly, by recording and measuring completion of our critical processes, we reinforce and encourage use of best practices. I kept the rows in chronological printing order, which directly tracked our output. However, because of the order number structure (3), sorting by order number grouped documents by product, title, and revision. Sorting on other columns yielded lists of documents by product, by release, by writer, or by month. Gradually, as we introduced new group processes, I recorded new information about our documents. http://tc.eserver.org/13147.html http://tc.eserver.org/13147.html Most planning methods do not account for the time and resource crunch that is a reality in today’s high-tech companies. However, there are techniques that you can use in all stages of a project that allow you to complete quality software documentation on time. Prepare to write the documentation by initiating pre-project activities, such as building relationships with developers, creating an outline, and participating in interface design development. Incorporate reviews and prioritize your work throughout the writing cycle. Address production and document management methods early on, and after completing the project, continue to solicit feedback from users and colleagues. http://tc.eserver.org/13105.html http://tc.eserver.org/13105.html Manufacturers are currently grappling with determining whether they should put safety information on the Web and if they do how it should be presented. Technical communicators, Web content developers, and Web designers will ultimately be responsible for the presentation of Web-based safety information. This article discusses special considerations that should be given the formatting (HTML, PDF, etc.), design, (font, size, and color), and location of safety information on the Web. Additionally, areas for future research on the issue of Web-based safety information are identified. http://tc.eserver.org/13108.html http://tc.eserver.org/13108.html To be effective, technical tutorials need to offer learners the opportunity to put information into action and to assess their performance through well designed practice sessions. Research findings on practice modules suggest the appropriate levels of difficulty, structure of practice sessions, and optimal forms of feedback.