Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.
#31582
This blog discusses documents and information designs “in the wild" - especially those that are exceptionally good or exceptionally bad.
Doc or Die. Resources>Documentation>Information Design>Blogs
#26372
DocBook provides a system for writing structured documents using SGML or XML. It is particularly well-suited to books and papers about computer hardware and software, though it is by no means limited to them.
#26373
This howto attempts to clear the fog and mystery surrounding the DocBook markup system and the tools that go with it. It is aimed at authors of technical documentation for open-source projects hosted on Linux, but should be useful for people composing other kinds on other Unixes as well.
Raymond, Eric S. tldp.org. Articles>Documentation>XML>DocBook
#26195
DocBook Element Quick Reference Card 
A one-page reference card for DocBook elements.
dpawson.co.uk (2004). Reference>Style Guides>Documentation>DocBook
#31161
Having new DocBook standards in place may do little to push adoption. An important factor in driving user adoption is the availability of software that implements the standard. It would be interesting to see whether big software companies would jump on the bandwagon...Unless the open-source community comes to the rescue!
Talbot, Fabrice. LiveTechDocs (2008). Articles>Documentation>XML>DocBook
#26193
Docbook Frequently Asked Questions
This is a collation of some Frequently Asked questions regarding Docbook. The initial focus will be on the XML version of the DTD, and the XSLT based stylesheets.
dpawson.co.uk (2005). Articles>Documentation>Standards>DocBook
#25442
DocBook is an XML vocabulary that is particularly well suited to books and papers about computer hardware and software.
SourceForge (2003). Resources>Documentation>Open Source>DocBook
#25443
DocBook is officially available as a [WWW] Document Type Definition (DTD) for both XML and SGML. It is unofficially available in other forms as well.
Docbook.org (2003). Resources>Documentation>XML>DocBook
#26192
These are XSL stylesheets for the DocBook DTD and its derivatives (Simplified DocBook, etc.) to generate PDF/print documents or Web/HTML content.
SourceForge (2005). Resources>Documentation>XSL>DocBook
#26196
DocBook XSL: The Complete Guide
DocBook is a collection of standards and tools for technical publishing. DocBook was originally created by a consortium of software companies as a standard for computer documentation. But the basic 'book' features of DocBook can be used for other kinds of content, so it has been adapted to many purposes.
Stayton, Bob. Sagehill (2005). Books>Documentation>XSL>DocBook
#26307
DocBook: An Introduction for Technical Writers
A set of slides that gives a brief introduction to DocBook and why it is useful for technical writers. Also available in PDF format.
Nesbitt, Scott. DMN Communications (2002). Presentations>Documentation>Standards>DocBook
#26191
This book is designed to be the clear, concise, normative reference to the DocBook DTD. This book is the official documentation for the DocBook DTD.
Walsh, Norman and Leonard Muellner. Docbook.org (2003). Books>Documentation>XML>DocBook
#10571
In two recent consulting projects, we worked with online documentation developers who wanted to understand the problems users encountered and how their documentation helped solve those problems. To find out, we went and observed users in their own work environments. Although the clients and their software differ significantly, we found similar issues.
User Interface Engineering (1998). Articles>Usability>Documentation
#22878
Document Design: A Brief Primer
Today's documentation must be designed with information retrieval as its key objective. When information is organized and mapped into a consistent, logical structure that uses retrievability aids such as labels that facilitate scanning, blocks of information, advance organizers for the information, keywords, meaningful indexes, and a hierarchical organization, readers can quickly locate and use the information that they need.
Flanders, Melanie G. STC Proceedings (1997). Articles>Documentation>Document Design>User Centered Design
#14541
Document Development: Getting the Technical Writer Involved Up Front
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.
Remington, Thomas F. STC Proceedings (1995). Presentations>Documentation>Methods
#20306
A Document Management Case Study: QLD Dept of Housing
How a new spin on document management software helped revolutionise customer service at the Queensland Department of Housing.
Hambly, Natalie. Cherryleaf (2003). Articles>Documentation>Software>Government
#23141
Document to the Question: Understanding What Users Ask and Where They Look for the Answers 
The user's idea of the problem is often very different than the help or program designer's. The online help topics often reflect the designer's viewpoint, not the user's.
STC India (2003). Articles>Documentation>User Centered Design>Help
#26262
Document your Database Project to Capture Relevant Info 
Documenting a database during its development is a best practice to ensure that the organizational schema, data objects, and other related information are captured for future reference.
Kelly, William T. Builder.com (2003). Articles>Project Management>Databases>Documentation
#20574
Documentation and Training Productivity Benchmarks 
Investigates how computer-industry companies create end-user documentation and training materials, and how they measure productivity. Describes results of interviews of eleven managers of publications or training departments.
Barr, John P. 'Jack' and Stephanie Rosenbaum. Technical Communication Online (2003). Articles>Documentation>Assessment
#25410
Documentation Confuses More Than it Clarifies
Vendors could make life for the user a lot easier if manual writers were familiar with the product.
Computing Canada (1999). Articles>Documentation
#24703
A Documentation Database for Managing Time and Costs
Keeping track of a technical writing team’s time can be a tedious task, especially when that time has to be charged to various internal departments. Using Lotus Notes™ (Lotus Development Corporation and Iris Associates, Inc.), we developed a relational database to track this information. This database uses a single form for all documentation status inputs. Then it summarizes the data in a variety of view. Separate forms track SEI statistics and simplify department employee time administration.
Lang, Darice and Debra Ricks. STC Proceedings (1994). Articles>Documentation>Project Management
#27590
With limited staff, a rapidly changing IT environment, and increasing complexity, my own inflexible documentation practices had to be updated to reflect more dynamic environments.
Dickerson, Chad. InfoWorld (2004). Articles>Documentation>Agile>Extreme Documentation
#28178
As technical writers, we work more online than ever before. We are beginning to work with documentation in a new way, so that we can repurpose content and free it from the restrictions imposed by any particular delivery mechanism. We no longer solely create paper-publishable documents. We do not, as yet, have a good word for what we do; we do not have a single word or phrase that summarizes the effort or the deliverables. Nor can we use any single existing lexicon because the concepts are new. This difficulty is a natural consequence of the inter-networked world in which we work, where information is delivered multiple ways for diverse audiences. But let us look at the phrases currently growing in popular usage that refer to this effort.
Albing, Bill, Michelle Corbin Nichols and Ann-Marie Grissino. Carolina Communique (2004). Articles>Documentation>Online
#24651
As technical communicators grapple with the changing processes and tools within which they work, we are seeing a gradual but dramatic evolution of technical writers into content developers.
Albing, Bill. KeyContent.org (2004). Articles>Documentation
#14740
Documentation for a Technical Audience
Liebhaber discusses the benefits of system documentation--documentation written for an audience of technical people who solve support problems or modify components to the software.
Liebhaber, Karen Powers. Intercom (2002). Articles>Documentation
