<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Documentation&gt;Content Management</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/Content-Management</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and Content Management 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;Documentation&gt;Content Management</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/Content-Management</link>
	</image>
	<item>
		<title>Using a Wiki for Technical Documentation</title>
		<link>http://tc.eserver.org/35841.html</link>
		<guid>http://tc.eserver.org/35841.html</guid>
		<description>Is it possible to use a wiki for technical documentation? Yes, most definitely. I started working on a wiki two years ago, with no prior experience of wikis (apart from the occasional encounter with Wikipedia) but with plentiful experience of technical writing. I’ve learned a lot and I’d like to pass on some tips to you too.</description>
	</item>
	<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>Documentation Collaboration Service</title>
		<link>http://tc.eserver.org/35617.html</link>
		<guid>http://tc.eserver.org/35617.html</guid>
		<description>Collaboration happens when multiple people work simultaneously towards a common goal. Collaboration software are tools which try to make working together easier and more productive.&#xD;&#xD;There are hundreds of methodologies and approaches out there to collaboration. We want to bring the focus on one particular dimension: open vs. structured collaboration.</description>
	</item>
	<item>
		<title>A Few Surprises in Using a Wiki for Documentation</title>
		<link>http://tc.eserver.org/35438.html</link>
		<guid>http://tc.eserver.org/35438.html</guid>
		<description>Recently I’ve been working on a simple calendar project that uses a wiki for documentation. Although I’ve heard a lot about using wikis for documentation, and have even used them in the past, I ran into a few surprises this time.</description>
	</item>
	<item>
		<title>Did Technical Documentation Play a Role in the White House&apos;s Decision to Move to Drupal?</title>
		<link>http://tc.eserver.org/35423.html</link>
		<guid>http://tc.eserver.org/35423.html</guid>
		<description>The reasons for the White House&apos;s decision to run its Web site, whitehouse.gov, on the open source content management system Drupal are being discussed on various Web sites. Alongside Drupal&apos;s functionality, flexibility and openness, some are suggesting that Drupal&apos;s documentation was also a key factor for deciding to use this system.</description>
	</item>
	<item>
		<title>Wiki as Forum, FAQ, HTML Editor, XML Editor, or CMS?</title>
		<link>http://tc.eserver.org/35403.html</link>
		<guid>http://tc.eserver.org/35403.html</guid>
		<description>A wiki can be a Frequently Asked Questions repository, much like the knowledge bases in their heyday in the late 80s. My favorite line from the blog entry has to be its closer: &apos;It&apos;s about a different way of thinking around how to interact with the community.&apos; And that is what I have explored with my wiki presentation, about how to build community with a wiki and be an active member of that community. But what are other uses of the wiki?</description>
	</item>
	<item>
		<title>Getting Content Into and Out of Wikis</title>
		<link>http://tc.eserver.org/35154.html</link>
		<guid>http://tc.eserver.org/35154.html</guid>
		<description>As wikis mature, we’re using them for more complex business cases such as technical documentation, business analysis and project management. It’s becoming more and more interesting, if not essential, for wikis to support the import and export of content to and from other formats. Most wikis allow you to convert their pages at least to PDF and HTML. But what of other formats, and what about tools for getting content into wikis as well as out of them?</description>
	</item>
	<item>
		<title>Authoring with Eclipse</title>
		<link>http://tc.eserver.org/35047.html</link>
		<guid>http://tc.eserver.org/35047.html</guid>
		<description> The topic of technical publishing is relatively new to the world of Eclipse. One can make the argument that technical publishing is just another collaborative development process involving several people with different backgrounds and skills. This article will show that the Eclipse platform is a viable platform for technical publishing by discussing how to write documents such as an article or a book within Eclipse. In fact, this article was written using Eclipse. </description>
	</item>
	<item>
		<title>Community and Documentation</title>
		<link>http://tc.eserver.org/35027.html</link>
		<guid>http://tc.eserver.org/35027.html</guid>
		<description>This chapter explores the idea that a small group of people who have a sense of belonging in an online community may provide content much like a technical writer does. Regardless of their background, education, or training, more people are becoming providers of technical information on the web.</description>
	</item>
	<item>
		<title>Care to Write Army Doctrine? With ID, Log On</title>
		<link>http://tc.eserver.org/35025.html</link>
		<guid>http://tc.eserver.org/35025.html</guid>
		<description>In July, in a sharp break from tradition, the Army began encouraging its personnel — from the privates to the generals — to go online and collaboratively rewrite seven of the field manuals that give instructions on all aspects of Army life.&#xD;&#xD;The program uses the same software behind the online encyclopedia Wikipedia and could potentially lead to hundreds of Army guides being “wikified.” The goal, say the officers behind the effort, is to tap more experience and advice from battle-tested soldiers rather than relying on the specialists within the Army’s array of colleges and research centers who have traditionally written the manuals.</description>
	</item>
	<item>
		<title>Producing Documentation and Reusing Information in XML, Part 1: Document Publishing Using XML</title>
		<link>http://tc.eserver.org/35017.html</link>
		<guid>http://tc.eserver.org/35017.html</guid>
		<description>XML provides a way to identify data items and subcomponents within any structured data set, but has its roots in documentation development and production. Robust, open standards for XML document markup and a rich set of freely available tools for XML document parsing and format conversion make it easy to install and configure a complete documentation development and formatting environment on any UNIX® or Linux® system.</description>
	</item>
	<item>
		<title>Producing Documentation and Reusing Information in XML, Part 2: Reuse Information in XML Documentation</title>
		<link>http://tc.eserver.org/35018.html</link>
		<guid>http://tc.eserver.org/35018.html</guid>
		<description>Discover simple solutions to reuse information in XML documentation, such as how to use XInclude to include other documents at a given point in a document and how to use XPointer to include small document fragments from other documents or a similar pool of information in XML format. Also, get tips for structuring XML documentation to simplify information reuse, and learn how to maintain stand-alone documents that you can incorporate into larger documents.</description>
	</item>
	<item>
		<title>Pick a Card</title>
		<link>http://tc.eserver.org/34704.html</link>
		<guid>http://tc.eserver.org/34704.html</guid>
		<description>There are obvious benefits to single sourcing, the ones that roll off the tongue the minute single source is mentioned: multi-format publishing, consistency of information, quicker updates of common content, lowering translation costs and so on. But beyond all those, what else is there? In this guest blog post, Gordon McLean discusses just that.</description>
	</item>
	<item>
		<title>Firefox’s Revolutionary Community Approach to Customer Support</title>
		<link>http://tc.eserver.org/34557.html</link>
		<guid>http://tc.eserver.org/34557.html</guid>
		<description>The Firefox Support Knowledge Base is a collaborative work of dozens of contributors, the Support Forum is bustling with people answering questions, and Live Chat is manned by dedicated team of community members.</description>
	</item>
	<item>
		<title>The Medium is the Delivery Method</title>
		<link>http://tc.eserver.org/34549.html</link>
		<guid>http://tc.eserver.org/34549.html</guid>
		<description>A question that technical communicators frequently ask about wikis is &quot;How do I get the documentation out of a wiki?&quot; A simple answer: &quot;Don’t worry about it.&quot; Because the wiki is the delivery method.</description>
	</item>
	<item>
		<title>Daisy: WYSIWYG Wiki for PDF Books</title>
		<link>http://tc.eserver.org/34492.html</link>
		<guid>http://tc.eserver.org/34492.html</guid>
		<description>If you need the collaborative aspects of a Wiki combined with DITA&apos;s modular topics and publishing capabilities, then DAISY might just be the system you need--and it&apos;s free. DAISY provides WYSIWYG editing for Wiki pages that can be combined to publish books, either in a PDF or as a single HTML page.</description>
	</item>
	<item>
		<title>Architecting User Assistance Topics for Reuse: Case Examples in DITA</title>
		<link>http://tc.eserver.org/34468.html</link>
		<guid>http://tc.eserver.org/34468.html</guid>
		<description>In this column, I’ll review what user assistance architects mean by reuse and what its benefits can be. I’ll then describe some different scenarios for reuse and offer guidelines that user assistance architects and information developers can follow. My examples show how DITA (Darwin Information Typing Architecture) can be an effective reuse framework. But the principles I discuss go beyond DITA, and you can apply them to any structured information framework or toolset.</description>
	</item>
	<item>
		<title>Wiki-fying Docs: Is Using Customer-Accessible Wikis for End-User Documentation Gaining Momentum?</title>
		<link>http://tc.eserver.org/34417.html</link>
		<guid>http://tc.eserver.org/34417.html</guid>
		<description>While the effort to provide more interactivity and power to the end-user seems to suggest that we open up a wiki to allow them to add and edit content, the basic idea of a set of edited documentation is now challenged with a social network of participating customers, all of whom may now edit, add, and delete content. How social can you go? This article is an attempt to look at the process of evaluating the use of a wiki for end-user documentation, if such a thing can exist. Are the two types of customer content — wikis and end-user documentation — mutually exclusive?</description>
	</item>
	<item>
		<title>The Many Faces of Content Management: A Primer</title>
		<link>http://tc.eserver.org/34411.html</link>
		<guid>http://tc.eserver.org/34411.html</guid>
		<description>None of the technologies mentioned so far support the production of content for purposes of producing technical documentation. Such a system is a specific type of content management that has specialized functions for technical communicators doing multi-channel publishing, yet it hasn&apos;t spun off its own specific acronym. </description>
	</item>
	<item>
		<title>Editing Modular Documentation: Some Best Practices</title>
		<link>http://tc.eserver.org/34350.html</link>
		<guid>http://tc.eserver.org/34350.html</guid>
		<description>The authors have come up with eight guidelines and three concrete suggestions on best practices for editing modular documentation, including ensuring that all topics are standalone, that titles are unique and descriptive, and more.</description>
	</item>
	<item>
		<title>Hey Rocky – Watch Me Pull a CMS Out of My HAT</title>
		<link>http://tc.eserver.org/34351.html</link>
		<guid>http://tc.eserver.org/34351.html</guid>
		<description>When companies decide whether or not to adopt a CMS or continue using a HAT, there are many factors to consider. Perlin outlines elements of both CMSs and HATs that could help you determine which is best for your organization.</description>
	</item>
	<item>
		<title>Authoring Eclipse Help Using DITA</title>
		<link>http://tc.eserver.org/34274.html</link>
		<guid>http://tc.eserver.org/34274.html</guid>
		<description>This page contains information about how to use DITA for authoring Eclipse Help.</description>
	</item>
	<item>
		<title>Advantages of Using Microsoft SourceSafe While Writing Your Technical Documents</title>
		<link>http://tc.eserver.org/34032.html</link>
		<guid>http://tc.eserver.org/34032.html</guid>
		<description>Microsoft’s Visual SourceSafe was not created with technical communicators in mind. It was created for engineers writing software source code. But it is successfully used by technical writers in offices around the world to control documentation.</description>
	</item>
	<item>
		<title>Web 2.0, Wikis, and Books</title>
		<link>http://tc.eserver.org/33645.html</link>
		<guid>http://tc.eserver.org/33645.html</guid>
		<description>The founder of FLOSS manuals discusses the intersection of books and Web 2.0 and the continuing evolution of publishing and technology.</description>
	</item>
	<item>
		<title>Consolidating Content Delivers More with Less</title>
		<link>http://tc.eserver.org/33636.html</link>
		<guid>http://tc.eserver.org/33636.html</guid>
		<description>Software products have found ways to share content and reuse content to deliver more value with limited resources. For example, fantasy football web sites share player news, injury reports, and game statistics. Security products often reuse security announcements and warnings from trusted sources, and present them as rebranded content. We are also seeing software vendors using Twitter and RSS feeds to distribute information and announcements. The next step is when these information feeds are integrated into the product user interface itself, making it the one stop resource for all the information needs of its users. No more need to use google when your product itself delivers the answers to all your questions from the sources you trust.</description>
	</item>
	<item>
		<title>It&apos;s In The Mix: The Next Generation Of Open Source Publishing</title>
		<link>http://tc.eserver.org/32680.html</link>
		<guid>http://tc.eserver.org/32680.html</guid>
		<description>The same principles behind music remixing are at the heart of a hugely important open source software documentation experiment, taking place on the web today. It’s called FLOSS Manuals, a content remixing project that provides its website visitors with the ability to read, write and remix documentation.</description>
	</item>
	<item>
		<title>Getting FLOSSy: Acrobat Killer Or HAT Replacement?</title>
		<link>http://tc.eserver.org/32146.html</link>
		<guid>http://tc.eserver.org/32146.html</guid>
		<description>Some writers truly hate Adobe Acrobat and any tool that can do the job better is worth a shot, particularly if it’s open source and easily navigated. Flossmanuals.net introduces FLOSS which does a lot of the single desktop Acrobat Pro’s job - collaboratively and open source.</description>
	</item>
	<item>
		<title>The Why and How of Content Convergence and Integration</title>
		<link>http://tc.eserver.org/31729.html</link>
		<guid>http://tc.eserver.org/31729.html</guid>
		<description>Content producers are about to live through interesting times, to adapt the popular saying, with the dawning of The Age of Content. Industry is discovering content as a commodity; the rules are changing, and fast. What have traditionally been seen as the lowliest form of commercial content within an enterprise, technical manuals, are starting to take their place alongside the other valued corporate assets.</description>
	</item>
	<item>
		<title>Moving Legacy Documentation into DITA: An Interview</title>
		<link>http://tc.eserver.org/30799.html</link>
		<guid>http://tc.eserver.org/30799.html</guid>
		<description>JoAnn Hackos, content management and information design expert, gives her best advice on what organizations need to know about moving legacy documentation to DITA.</description>
	</item>
	<item>
		<title>The New World of Product Labeling: Alternative Architectures and Approaches</title>
		<link>http://tc.eserver.org/30798.html</link>
		<guid>http://tc.eserver.org/30798.html</guid>
		<description>A discussion of the shift to structured content in pharmaceutical product labeling, which builds upon SPL and PIM regulations and the fundamental concepts of enterprise content management.</description>
	</item>
	<item>
		<title>Structured Document Processors: Customizing Software to Control Document Development Processes</title>
		<link>http://tc.eserver.org/30583.html</link>
		<guid>http://tc.eserver.org/30583.html</guid>
		<description>Structured document processors (SDPS) enable companies to make document production more efficient and accurate, while improving reliability of documents that must be updated frequently or written to very strict format standards. Achieving these goals requires elaborate and highly technical customization of the SDP. This paper emphasizes the importance of collaboration in customizing SDPS to particular document development processes. Three case histories illustrate the spectrum of ways industry is using SDPS for writing, showing three different approaches to customizing SDPS.</description>
	</item>
	<item>
		<title>Is a Documentation Wiki in your Future?</title>
		<link>http://tc.eserver.org/29554.html</link>
		<guid>http://tc.eserver.org/29554.html</guid>
		<description>If we can solicit user participation in a Web 2.0 knowledge community (a volunter wiki documentation, for example), we might have a powerful means for creating high quality content. But how should this process work?</description>
	</item>
	<item>
		<title>Meaningful Microcontent</title>
		<link>http://tc.eserver.org/27593.html</link>
		<guid>http://tc.eserver.org/27593.html</guid>
		<description>Microcontent refers to small, granular, and possibly representative (that can provide a summary of or a navigation to a larger set of information) bits of information, typically available on the Web. An example in the domain of journalism might be headlines and news summaries, small bits of content that can be used on a front page of the news with links to more in-depth articles. The definition has grown in scope as much as in its application.</description>
	</item>
	<item>
		<title>An Overview of Single Sourcing with an XML Content Management System</title>
		<link>http://tc.eserver.org/25378.html</link>
		<guid>http://tc.eserver.org/25378.html</guid>
		<description>Creating an XML-based Content Management System to single-source technical publications is as simple as 1 - 2 - 3. OK, maybe it isn&apos;t quite that easy, but this article discusses how it can be done.</description>
	</item>
	<item>
		<title>Implementing a Document Control System</title>
		<link>http://tc.eserver.org/24700.html</link>
		<guid>http://tc.eserver.org/24700.html</guid>
		<description>Document control is a major component of any quality system. To implement a document control system, first establish Policies/procedures for generating, approving, issuing, and revising documents. The next step is to design and implement forms and a filing system/data base for managing quality documents. Teamwork and established guidelines can help ease the complexities of implementing a document control system.</description>
	</item>
	<item>
		<title>A Case Study in Developing Dynamic Content at Ontario Systems</title>
		<link>http://tc.eserver.org/23634.html</link>
		<guid>http://tc.eserver.org/23634.html</guid>
		<description>Charles Cantrell, an Information Engineer, describes Ontario Systems&apos; process for delivering dynamically assembled and populated documentation for Artiva, its &apos;highly customizable&apos; accounts receivable management application.</description>
	</item>
	<item>
		<title>Customizing the Appearance of Your Manual, Help System, and HTML Help System</title>
		<link>http://tc.eserver.org/21474.html</link>
		<guid>http://tc.eserver.org/21474.html</guid>
		<description>Doc-To-Help gives Help authors complete control over the look, feel, and content of a project&apos;s printed manual, Windows Help system, HTML files, and HTML Help system. Maintaining different content is controlled using Doc-To-Help&apos;s conditional text feature, which allows authors to mark content for print-only, online-only, WinHelp-only, and so on. In this article we discuss how you control the appearance of the printed manuals and Help using Word templates, and HTML output using cascading style.</description>
	</item>
	<item>
		<title>We Neurotic Amateurs: A Commentary on Edmond H. Weiss&apos;s &quot;Egoless Writing: Improving Quality by Replacing Artistic Impulse with Engineering Discipline&quot;</title>
		<link>http://tc.eserver.org/20349.html</link>
		<guid>http://tc.eserver.org/20349.html</guid>
		<description>The assertion that technical communicators tend to be &apos;amateurs&apos;--that is, lovers of our own work--is a claim with little foundation. Arguments toward regimentation and systematization of documentation writing are not calls to professionalize a currently-immature field, but rather attempts to emulate the hierarchy we have seen implemented in microprocessor engineering in the 1970s, software development in the 1980s, and content management in the 1990s. Such &apos;egoless&apos; methods may offer advantages to employers, but should not necessarily be considered &apos;progress.&apos;</description>
	</item>
	<item>
		<title>Going Online: A Case Study in the Development and Implementation of Netscape NetHelp</title>
		<link>http://tc.eserver.org/20332.html</link>
		<guid>http://tc.eserver.org/20332.html</guid>
		<description>Computerized Medical Systems, Inc. (CMS) - the worldâ*™s leading radiation therapy planning (RTP) company with over 1000 installed RTP systems and over 400 installed dosimetry systems - decided in late 1996 to move existing FOCUS documentation online. Reasons for this&#xD;included: the existing documentation set perceived as too&#xD;difficult to use; increasing printing cost; and customer&#xD;feedback. Using Netscape NetHelp as a basis, the CMS documentation staff reduced printed documentation size by two-thirds while making the information more&#xD;accessible. Reactions to FOCUSHelp have been highly&#xD;favorable. Future plans include migrating to the&#xD;NetHelp2 framework and reducing topic lengths.</description>
	</item>
	<item>
		<title>Restructuring Your User Information</title>
		<link>http://tc.eserver.org/19383.html</link>
		<guid>http://tc.eserver.org/19383.html</guid>
		<description>Details a process for improving the usability, consistency, and organization of user information within businesses that maintain medium to large documentation libraries.</description>
	</item>
	<item>
		<title>Egoless Writing: Improving Quality by Replacing Artistic Impulse With Engineering Discipline</title>
		<link>http://tc.eserver.org/15086.html</link>
		<guid>http://tc.eserver.org/15086.html</guid>
		<description>When technical communicators have a strong personal attachment to the publication they are preparing, this attachment may interfere with the design and testing of the publication itself. Documents developed by solo authors tend to be late, buggy, and exceedingly difficult for others to maintain. &apos;Ego-less&apos; methods---collaborative and structured---break the proprietary connection between the writer and the book; in so doing they permit the most powerful tools of engineering and testing to be used. But they also reduce the satisfactions of the communicator&apos;s job.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/Content-Management.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>