#31815
Documentation Methods for AACSB Learning Assurances 
In 2003, the Association to Advance Collegiate Schools of Business (AACSB) redefined their accreditation and reaffirmation standards to move from a traditional outcome-based system to a systematic process-based review. Documentation is required to assure student learning in several core areas, including communication. This paper outlines the data collection procedures and documentation methods used to document one university’s business communication learning assurances.
Gueldenzoph, Lisa E. Association for Business Communication (2008). Articles>Documentation>Education>Business Communication
#15117
Documentation Metrics: What Do You Really Want to Measure?
Examines several metrics--systems for measuring production and production standards--to determine their value to technical communicators. He argues that qualitative metrics are more meaningful than quantitative ones.
Le Vie, Donald S., Jr. Intercom (2000). Articles>Documentation>Assessment>Heuristic Evaluation
#23580
Documentation on CD-ROM: Strategies for a Successful Implementation
Producing documentation on CD-ROM can be extremely beneficial to users and can also save your company a lot of money over hard copy costs. To assure a successful roll-out of your CD product, it is critical to consider the involvement of key departments in your company as you plan the implementation in your user community. The two processes are closely related, and a well-integrated internal plan will help assure a successful introduction to your customers.
Florsheim, Stewart J. STC Proceedings (1994). Articles>Documentation>Online
#28281
Documentation Quality Checklist
Basic checklist for assessing and improving the quality of technical documentation, especially software documentation such as user manuals, online help files, interactive demos and tutorials.
Achtelig, Marc. indoition engineering (2006). Articles>Documentation>Quality>Documentation
#28172
To implement any continuous improvement process, you have to measure your progress. This is where metrics come in. Have you been struggling to create a process for measuring your technical documentation? If so, this article provides the information you need to get started.
Cohen, Jules. Carolina Communique (2004). Articles>Documentation>Assessment
#23587
Documentation Quality Metrics Within Total Quality Management Systems
Total Quality Management (TQM), is now very much a feature of many organizations. One of the kernels of TQM is the process, with its related topics such as process design, process management and process improvement. One of the key requirements for process design and management is process measurements, often called 'metrics'. Within the document design and development process, process metrics, including quality metrics, must be based very strongly on customer values for documentation. Quality metrics can form one element within a composite customer satisfaction index for documentation projects.
Hosier, William J. STC Proceedings (1994). Articles>Documentation>Quality
#23221
Funny thing, documentation. Ought to be easy enough, surely? So why the disappointing results? What IS the elusive spark which distinguishes the professional author from others who put their hand to the pen (keyboard)?
Mobbs, John. ISTC (2002). Articles>Documentation>Writing>Technical Writing
#29771
Documentation Solutions for Complex Tools: Task-Based Design at the Cross Roads
For most of the technical writing community, task-based documentation has become the panacea for presentation of end-product document (in any of its myriad forms including traditional linear manuals and online help). We believe, however, that applying this method to a complex tool, (for example, a software tool without a Graphical User Interface), challenges the task-based approach.
Swallow, Lisa and Matt Laney. STC Proceedings (2004). Articles>Documentation>Writing>Technical Writing
#23645
Documentation Through the Discovery Process
The technical writers at a software company learn about the software by gathering information and running the software themselves.
Kloss, Marilyn B. STC Proceedings (2003). Articles>Documentation>Interviewing
#14753
Documentation through the Discovery Process
Kloss describes a process of composing documentation that requires the writer's involvement at every phase of product development.
Kloss, Marilyn B. Intercom (2002). Articles>Documentation>Style Guides
#31006
Documentation: Give It Up; It Won't Happen
Is providing Linux documentation an insurmountable task? I'm starting to think so. The major technical book publishers have dropped their efforts to recruit authors and publish sysadmin books. Instead, they have started focusing most of their attention on programming. Who can blame them.
Adelstein, Tom. Linux Journal (2007). Articles>Documentation>Operating Systems>Linux
#21025
Documenting Entertainment Software: The Mixed Challenge of Simplicity and Sophistication
The challenges of documenting entertainment software are in many ways the challenges of all technical communicators. We strive to make the interface intuitive and the documentation interesting and easy-to-read. Although the nature of the world of entertainment may suggest that our task is simple, the breadth of our audience and the depth of our goals makes it more sophisticated than it looks. We must be as imaginative as our users, recognize the emerging dimensions of multimedia, and create with the constraints of low retail costs, small teams, and fast-paced deadlines.
Guthrie, Lynn Frances. STC Proceedings (1995). Articles>Documentation>Software
#28173
It is commonplace to find information through the Web, but the use of the Web for technical communication is still uncommon. What the competition entries made me realize is that in this networked world, the places where we find information are no longer one or two dimensional. Communication is no longer simply about words on a page (or on a screen). Technical information is now accessed through a multidimensional cyberspace.
Albing, Bill. Carolina Communique (2004). Articles>Documentation>Online
#25379
Documenting in N-Dimensional Space
As technical communicators, we are being challenged with how to structure information in a multiple dimensional space made possible with Web technology.
Albing, Bill. KeyContent.org (2005). Articles>Documentation>Information Design
#15118
Documenting ISO 9001 Compliance
Describes how technical writers can make their documentation comply with ISO 9001, the latest quality management system from the International Organization for Standardization. The article includes a list of suggested readings.
Parr, Kelly A. Intercom (2002). Articles>Documentation>Standards>ISO 9001
#28734
Documenting networks is playing less with words, and more with diagrams. It also requires an engineering mind, an ability to think out-of-box, and creative mind. Technical writers can rise to a new scale and expand their skill sets if they are able to document networks.
EDITsphere (2007). Articles>Documentation>Intranets>Graphic Design
#24215
Documenting Procedures After the Sole Subject Expert Has Left the Organization
A corporation's or nonprofit's life without written procedures is fraught with dangers and pitfalls that can strike without warning and potentially wreak havoc on the organization's ability to function efficiently—or even to function at all—especially when the lone source of how-to information leaves the organization. The task of creating those procedures from scratch from what often amounts to skeleton information and secondhand sources can be tedious and frustrating but well worth the effort if it helps prevent the organization from being caught off guard in the future. When it comes to workplace procedures, it pays to be prepared.
Kessler, Audrey Cielinski. STC Proceedings (1999). Articles>Documentation>Policies and Procedures
#21657
The issue of documenting schemas—or any machine readable language—goes beyond simple additions of comments. Thereal challengeistocreateschemasthat arereadablebothdirectlybylookingat their sourcecodeandbydocumentation extraction tools.
van der Vlist, Eric. O'Reilly and Associates (2001). Articles>Information Design>XML>Documentation
#21504
Documenting the Flow of Rule-Based Programming in Expert Systems
With the spread of new technology, technical communicators face interesting new challenges for solving documentation problems. One area of software development that technical communicators are increasingly becoming involved in is that of rule-based expert systems. Because of their complexity, both the systems and their documentation can be difficult to maintain. Technical communicators can solve some of these maintenance problems by flow-charting only the chaining structure of the rule-base design.
Glover, Kyle S. STC Proceedings (1994). Articles>Documentation>Programming>Workflow
#30781
While the jobs of Mary Clouse and the rest of the Security and Documentation Unit of the New York State Senate Technology Services department aren't as glamorous as those of the senators themselves, they ensure that the Senate can use its automated systems to conduct its daily business smoothly, efficiently, and securely.
Clouse, Mary. Intercom (2008). Articles>Documentation>Workflow
#27501
There are four tiers of documentation recommended for satisfying ISO 9000 requirements. These documents are: the Quality Policy Manual, Procedures, Work Instructions, and Records.
Kurtus, Ron. School for Champions (2005). Articles>Documentation>Workplace>ISO 9000
#31035
Documents That No Project Cannot Be Without
Short deadlines force project teams to quickly design, test, and release the product with little or no design documentation. If these documents are written, they generally are not well-written and are not comprehensive. The fact of the matter is that most project teams do not have enough staff to design the product, let alone write and manage documentation. This situation creates an ideal opportunity for technical writers to assist the project team in more ways than writing a user guide.
Dick, David J. Carolina Communique (2008). Articles>Documentation>Project Management>Collaboration
#27574
Does a Good User Interface Obviate the Need for Documentation?
This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.
Sprezzatura Systems (2002). Articles>Documentation>User Interface>Software
#24890
Downsizing Documentation: Meeting the Challenge
The redesign of the Microsoft Windows operating system along with a shrinking page count and Help file-size allocation, presented Windows User Education with a unique opportunity. We not only redesigned our entire documentation model, we also changed and improved our authoring tools. And, along the way, we changed how we did our work.
Bloch, Peggy, Phyllis Levy, Kimberly A. Parris and Gayle Picken. STC Proceedings (1995). Articles>Documentation>Technical Writing>Minimalism
#31988
A Dozen Techniques to Improve Your Software Online Help
There are several main reasons why putting your software manual on-line is necessary. It makes your web-site attractive for search engine crawlers and therefore brings you targeted traffic from Google, Yahoo!, MSN, and other search engines. A good online manual presents your product as serious and credible. Moreover, if a user faces difficulty using your software and asks for technical support, you may easily resolve the issue by referring that user to a certain page of your online help. Simply give the page's URL. With just one click the user will see screenshots and explanations which will help them to resolve the issue.
Crane, Dennis. Dr. Explain (2005). Articles>Documentation>Online>Help
