<?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;Software</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/Software</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and Software 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;Software</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/Software</link>
	</image>
	<item>
		<title>Why Help Authoring Tools Will Fade</title>
		<link>http://tc.eserver.org/35839.html</link>
		<guid>http://tc.eserver.org/35839.html</guid>
		<description>Using any of the standard authoring tools — Flare, RoboHelp, Author-It, Doc-to-Help — leaves you with the ridiculous model of a single author working from a single vantage point from a single organization trying to pull together an ocean of information.  Because that model is untenable and unscalable, HATs will fade in favor of collaborative web-based authoring technologies.</description>
	</item>
	<item>
		<title>Writing Great Documentation: What to Write</title>
		<link>http://tc.eserver.org/35708.html</link>
		<guid>http://tc.eserver.org/35708.html</guid>
		<description>Tech docs can take a bunch of different forms ranging from high-level overviews, to step-by-step walkthroughs, to auto-generated API documentation. Unfortunately, no single format works for all users; there’s huge differences in the way that people learn, so a well-documented project needs to provide many different forms of documentation.</description>
	</item>
	<item>
		<title>To the Man With a Hammer Everything Looks Like a Nail</title>
		<link>http://tc.eserver.org/35414.html</link>
		<guid>http://tc.eserver.org/35414.html</guid>
		<description>An engineer at a company once called me and asked me how much it would cost to edit a Service Manual that he had written for a medical device. I asked him to send it to me so that I could give him a quote. When I received it I saw to my amazement and horror that he had written a 200 page manual (including many graphics) in Excel. When I asked him why he didn&apos;t use Word, he replied &apos;I&apos;m an engineer I know how to use Excel, not Word.&apos;</description>
	</item>
	<item>
		<title>Choosing a Help Authoring Tool</title>
		<link>http://tc.eserver.org/35339.html</link>
		<guid>http://tc.eserver.org/35339.html</guid>
		<description>Help authoring tools (HATs) are specialized editors and converters to create online technical documentation. Today, many help authoring tools also provide features for single source publishing, which means that you can generate several output formats and versions from one shared text source. While most tools manage to produce different online formats like browser-based help and compiled help very well, only few tools can also produce printed user manuals (or PDF) of professional quality. Big differences also exist between the tools when it comes to translating your projects into foreign languages.</description>
	</item>
	<item>
		<title>Choosing a Screen Capture Tool</title>
		<link>http://tc.eserver.org/35340.html</link>
		<guid>http://tc.eserver.org/35340.html</guid>
		<description>Checklist of key criteria for selecting a tool to take screen captures (screenshots / screen dumps). Screen captures are used within all forms of software documentation, such as user manuals, online help files, interactive demos and tutorials, but also for web sites and brochures.</description>
	</item>
	<item>
		<title>Choosing a Screencasting Tool</title>
		<link>http://tc.eserver.org/35341.html</link>
		<guid>http://tc.eserver.org/35341.html</guid>
		<description>Checklist of key criteria for selecting a tool to create interactive software demos (so-called screencasts). Software demos are not only used on web sites but increasingly also as standalone tutorials or embedded within online help files and other sorts of software documentation.</description>
	</item>
	<item>
		<title>Marktüberblick Screencasting Tools</title>
		<link>http://tc.eserver.org/35348.html</link>
		<guid>http://tc.eserver.org/35348.html</guid>
		<description>Marktüberblick über empfehlenswerte Tools zum Erstellen von Software-Demos (engl. Screencasts). Software-Demos werden nicht nur für Marketing-Zwecke auf Webseiten verwendet, sondern häufig auch als Ergänzung zur Technischen Dokumentation von Software: z.B. als eigenständiges Tutorial oder auch als integrativer Bestandteil einer Online-Hilfe oder sonstiger Software-Dokumentation.</description>
	</item>
	<item>
		<title>Authoring Tools Do Matter</title>
		<link>http://tc.eserver.org/34710.html</link>
		<guid>http://tc.eserver.org/34710.html</guid>
		<description>The authoring tool does matter. Writers are focusing on the wrong set of issues (leading, kerning, print formatting), none of which is actually relevant for the output.</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>Using Master Pages in RoboHelp 8</title>
		<link>http://tc.eserver.org/34357.html</link>
		<guid>http://tc.eserver.org/34357.html</guid>
		<description>Master Pages, a new concept introduced in Adobe RoboHelp 8, intends to provide flexibility in controlling the layout of topics, where in an author may separate the actual content from the layout of the output and may do it from a single place. In Adobe RoboHelp 8, a user may use Master Page as a Layout and Styling canvas where one may put basic HTML elements to be used for Layout purposes.</description>
	</item>
	<item>
		<title>Guidelines for Good Sample Code</title>
		<link>http://tc.eserver.org/33893.html</link>
		<guid>http://tc.eserver.org/33893.html</guid>
		<description>Sample code often provides the quickest, clearest way to learn how an SDK works. If you have software engineering experience, then you should already know many principles for writing good code. However, what you may not realize is that some of the good practices that you learned for writing good production code do not apply to writing good sample code. Some techniques, such as comments and clear variable names, apply to both production code and sample code. However, there are good reasons to use hard-coded values in sample code, which should be avoided in production code, and there are good reasons to avoid object-oriented designs when writing sample code.</description>
	</item>
	<item>
		<title>Writing Technical Documentation with Sphinx, Paver, and Cog</title>
		<link>http://tc.eserver.org/33725.html</link>
		<guid>http://tc.eserver.org/33725.html</guid>
		<description>I&apos;ve been working on the Python Module of the Week series since March of 2007. During the course of the project, my article style and tool chain have both evolved. I now have a fairly smooth production process in place, so the mechanics of producing a new post don&apos;t get in the way of the actual research and writing. Most of the tools are open source, so I thought I would describe the process I go through and how the tools work together.</description>
	</item>
	<item>
		<title>Flexibility and Adaptability</title>
		<link>http://tc.eserver.org/33696.html</link>
		<guid>http://tc.eserver.org/33696.html</guid>
		<description>There’s a lot of tool fetishism in the documentation world. We all succumb to it in one way or another — I used to think it was FrameMaker or DocBook, or nothing. Ah, the folly of youth. But that attitude severely limits you as a professional. For a consultant or freelancer, it’s only a few steps away from suicide.</description>
	</item>
	<item>
		<title>Ten RoboHelp Tips You Won&apos;t Want to Miss</title>
		<link>http://tc.eserver.org/33608.html</link>
		<guid>http://tc.eserver.org/33608.html</guid>
		<description>I&apos;ve been using RoboHelp for nearly a decade now. I started off with an older Word-based version to create WinHelp, and now I work with the HTML version to create WebHelp for locally installed and server-based products. Here are a few RoboHelp tips that I&apos;ve found useful in my day-to-day help authoring responsibilities.</description>
	</item>
	<item>
		<title>Eight Steps to Successful Software Documentation</title>
		<link>http://tc.eserver.org/32204.html</link>
		<guid>http://tc.eserver.org/32204.html</guid>
		<description>Whether software documentation is designed for a company’s internal users or for a variety of end customers, one thing is for certain: Documentation that is well written, well structured, easily accessible, and thoroughly compliments the software it supports can play a significant role in a product’s overall success. And it doesn’t matter if the documentation stands alone or it is integrated with the product. As long as it is properly planned, developed, and configured, success is eminent.</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 First Line of Support</title>
		<link>http://tc.eserver.org/31727.html</link>
		<guid>http://tc.eserver.org/31727.html</guid>
		<description>Customer support costs account for as much as 60 percent of a high-tech company’s total costs. Documentation is the first line of support for most customers, and customers usually use documentation to find the answer to a problem they’re having. The inevitable result of poor or nonexistent documentation is that more people try calling the customer support lines for help.</description>
	</item>
	<item>
		<title>Language Quality-Assurance Software</title>
		<link>http://tc.eserver.org/31353.html</link>
		<guid>http://tc.eserver.org/31353.html</guid>
		<description>Explores the benefits of using Language QA Software to optimize documentation for organizations and companies.</description>
	</item>
	<item>
		<title>Why Software Applications Need Product Blogs, and Why They Don&apos;t Get Them</title>
		<link>http://tc.eserver.org/31172.html</link>
		<guid>http://tc.eserver.org/31172.html</guid>
		<description>I&apos;m convinced that even internal software, which never sees the light of WWW, still needs a blog as much or more than products sold online. Even so, numerous corporate restrictions, standards, and culture will present seemingly insurmountable barriers to blogs.</description>
	</item>
	<item>
		<title>XML Documentation: The Missing Link (1)</title>
		<link>http://tc.eserver.org/31165.html</link>
		<guid>http://tc.eserver.org/31165.html</guid>
		<description>Technical documentation is a prime beneficiary of XML technology, with standards such as DocBook and DITA. However, while XML revolutionized the way technical documentation is written, it did nothing to help documentation teams improve the collaboration process with the SMEs and other invested parties. In some cases, things got worse, with another layer of complexity added between the documentation team and the documentation stakeholders. Where is the missing link?</description>
	</item>
	<item>
		<title>XML Documentation: The Missing Link (2)</title>
		<link>http://tc.eserver.org/31166.html</link>
		<guid>http://tc.eserver.org/31166.html</guid>
		<description>Sharing XML documents during the writing and review process is a missing link in the XML publication chain. While Office or PDF applications help, they also add another extra-layer of complexity and lose the &apos;XML awareness&apos; of our initial document. That&apos;s where LiveTechDocs comes into play.</description>
	</item>
	<item>
		<title>XML Editors for Technical Documentation</title>
		<link>http://tc.eserver.org/31164.html</link>
		<guid>http://tc.eserver.org/31164.html</guid>
		<description>Looking through my Programs folder, I see many programs I use to work with XML documentation. Which one is my favorite? Well, that depends on the size of my project, the size of my budget, and the file I am working on.</description>
	</item>
	<item>
		<title>Der Weg zum absoluten PDF-Standard in der Technischen Dokumentation</title>
		<link>http://tc.eserver.org/31150.html</link>
		<guid>http://tc.eserver.org/31150.html</guid>
		<description>Kein Wunder müssen Technischen Redakteure die ganze Zeit Druckdaten aufbereiten, wenn jede Druckerei ein anderes Datenformat verlangt. Eine Lösung musste her. Ein Standard. Und so ist auch PDF/X-3 ein Thema in der Technischen Dokumentation.</description>
	</item>
	<item>
		<title>The Importance of Software Documentation Standards</title>
		<link>http://tc.eserver.org/30830.html</link>
		<guid>http://tc.eserver.org/30830.html</guid>
		<description>The look and feel of a help system can differ greatly from one product to the next, as can the writing. So how can the technical writing community emphasize the importance of software documentation standards and create a more unified help experience that users can adapt to?</description>
	</item>
	<item>
		<title>Editing Guidelines for Software Documentation</title>
		<link>http://tc.eserver.org/30814.html</link>
		<guid>http://tc.eserver.org/30814.html</guid>
		<description>Software documentation can be difficult to review, so it helps to have some editing guidelines to keep you focused. Let&apos;s face it; software documentation isn&apos;t exactly exciting reading material. But you should be able to complete the job in a productive manner if you keep your coffee cup full and follow the editing guidelines below.</description>
	</item>
	<item>
		<title>Twenty-Two Tips for Writing Software Documentation Users Will Actually Read</title>
		<link>http://tc.eserver.org/30815.html</link>
		<guid>http://tc.eserver.org/30815.html</guid>
		<description>How do you go about writing technical manuals for software without going insane? Here are some guidelines you can follow to maintain your sanity when writing software documentation.</description>
	</item>
	<item>
		<title>All About Madcap Flare</title>
		<link>http://tc.eserver.org/30772.html</link>
		<guid>http://tc.eserver.org/30772.html</guid>
		<description>Madcap Flare is one of the most powerful online help authoring tools on the market today. In this podcast, Paul Pehrson, MVP in the Madcap Software forums, talks about Madcap Flare in depth.</description>
	</item>
	<item>
		<title>Why Wise Users May Not Read Computer Documentation</title>
		<link>http://tc.eserver.org/30619.html</link>
		<guid>http://tc.eserver.org/30619.html</guid>
		<description>Wise computer users may not read documentation because they do not have time to read all the material that is shipped with software products and because the useful lifetime of documentation is so short. This proposition is supported by statistics for a sample of manuals for typical commercial software.</description>
	</item>
	<item>
		<title>Systems and Programming Documentation for Technical Writers with No Data Processing Background</title>
		<link>http://tc.eserver.org/30585.html</link>
		<guid>http://tc.eserver.org/30585.html</guid>
		<description>This workshop teaches technical communicators what to include in internal documentation, how to interview and work with technical people, and basics of how to &apos;read&apos; and evaluate code.</description>
	</item>
	<item>
		<title>Preserve Changes in RoboHelp for a Linked FrameMaker Book</title>
		<link>http://tc.eserver.org/30457.html</link>
		<guid>http://tc.eserver.org/30457.html</guid>
		<description>While it is ideal to maintain all the content in FrameMaker, there are special situations which may require the RoboHelp content to be out of sync from FrameMaker documents either for short duration or for small set of topics.  These special situations can relate to project deadlines or project requirements which make the process of maintaining a single source difficult.</description>
	</item>
	<item>
		<title>Accommodating Active Learners in Software Documentation Decisions</title>
		<link>http://tc.eserver.org/30382.html</link>
		<guid>http://tc.eserver.org/30382.html</guid>
		<description>Recent research focusing on a minimalist approach to computer software documentation has explored ways to design computer software tutorials and workbooks for users with an active learning style. The principles of minimalism and active learning styles, however, are less frequently applied to traditional reference manuals. This paper reviews several elements of minimalism and suggests ways to apply strategies for active learners to traditional reference manuals.</description>
	</item>
	<item>
		<title>Evaluating the Effect of Iconic Linkage on the Usability of Software User Guides</title>
		<link>http://tc.eserver.org/29126.html</link>
		<guid>http://tc.eserver.org/29126.html</guid>
		<description>This study investigates whether Iconic Linkage--the use of the identical wording to present the same information recurring in a text--can improve the usability of user guides. Iconic Linkage is a writing strategy that potentially allows users to work more quickly and effectively and which promotes better retention of information. The usefulness of Iconic Linkage was tested in a laboratory-based usability study that combined: 1) objective task-based evaluation; and 2) users&apos; subjective evaluations of a software program used in recording parliamentary debates. A post-test survey designed to test subjects&apos; retention of information contained in the user guides was also administered. The study shows that Iconic Linkage significantly improved usability of the user guide: in all tasks, subjects worked more effectively and made fewer mistakes; while in the three timed tasks, subjects completed the tasks much more quickly. Subjects also gave higher ratings for the software and their retention of information was noticeably improved.</description>
	</item>
	<item>
		<title>John Daigle on RoboHelp 7</title>
		<link>http://tc.eserver.org/28789.html</link>
		<guid>http://tc.eserver.org/28789.html</guid>
		<description>Daigle, an Adobe community expert for RoboHelp, shares his reaction to the RoboHelp 7 sneak peak, and also explains the main features RoboHelp 7 will have: drag-and-drop functionality across the topics, double-byte language support for translation, the ability to have multiple topics open at the same time, snippets with graphics, removal of kadov tags, automatic breadcrumbs, and tighter integration with other Adobe products. Daigle speculates on reasons for Adobe&apos;s lack of transparency, and comments on the globalization of Adobe&apos;s development for RoboHelp.</description>
	</item>
	<item>
		<title>Audacity Tutorial: How to Record and Edit Audio with Audacity</title>
		<link>http://tc.eserver.org/28489.html</link>
		<guid>http://tc.eserver.org/28489.html</guid>
		<description>Audacity is a free cross platform multi track audio editing program from Sourceforge.net. It will let you record, edit, and mix an unlimited number of tracks. Audacity runs on Windows (98 through XP), Mac OS X, and Linux.</description>
	</item>
	<item>
		<title>Automating Production with WebWorks AutoMap</title>
		<link>http://tc.eserver.org/28153.html</link>
		<guid>http://tc.eserver.org/28153.html</guid>
		<description>WebWorks AutoMap is an extremely useful tool for performing unattended documentation builds. Out of the box, AutoMap can generate reasonable documents. By adding the power of scripting, the results can be amazing.</description>
	</item>
	<item>
		<title>Best Practice Flare: High Definition PDF</title>
		<link>http://tc.eserver.org/28027.html</link>
		<guid>http://tc.eserver.org/28027.html</guid>
		<description>Having introduced the concept of high definition PDF&apos;s output straight from Flare&apos;s source files with minimal post-production, we can now start to dig into the technologies that are used to produce it.</description>
	</item>
	<item>
		<title>Flare 5: Adding Advanced HTMLHelp Features</title>
		<link>http://tc.eserver.org/28030.html</link>
		<guid>http://tc.eserver.org/28030.html</guid>
		<description>Flare current provides the majority of HTMLHelp settings, and does this in a much more flexible way that HTMLHelp workshop does. Particularly useful are the WYSIWYG help window size and potitioning.&#xD;&#xD;However, there are some advanced HTMLHelp settings (such as advanced help, or remembering the users last help settings) that are not currently available.</description>
	</item>
	<item>
		<title>The Future of RoboHelp?</title>
		<link>http://tc.eserver.org/27646.html</link>
		<guid>http://tc.eserver.org/27646.html</guid>
		<description>The RoboHelp help authoring tool is now entering its thirteenth year of existence. That&apos;s a remarkably long existence for any software title. In that time period, we have seen an amazing expansion of the software industry throughout the 1990s and an equally amazing retraction due to the bursting of the Internet bubble. Making its start in the tiny offices of Blue Sky Software in LaJolla, California, RoboHelp grew into an extremely profitable product. It is also a market leader—having capturing some two-thirds of all Help authoring tool sales. During the Internet bubble years the company changed its name to eHelp, but RoboHelp continued to be its flagship profit center. In 2003, eHelp (and RoboHelp) were acquired by one of the leading providers of web tools—Macromedia. Now it appears that the end may be approaching for RoboHelp.</description>
	</item>
	<item>
		<title>Does a Good User Interface Obviate the Need for Documentation?</title>
		<link>http://tc.eserver.org/27574.html</link>
		<guid>http://tc.eserver.org/27574.html</guid>
		<description>This question was raised on a programmer&apos;s group recently and I was intrigued. The programmer&apos;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&apos;t read it although this makes me wonder who&apos;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.</description>
	</item>
	<item>
		<title>Writing Documentation and Help for Eclipse Projects and Plugins</title>
		<link>http://tc.eserver.org/26936.html</link>
		<guid>http://tc.eserver.org/26936.html</guid>
		<description>Eclipse is an open-source community. One of its primary projects is the creation of &apos;an extensible development platform...for building software.&apos; This platform takes shape in the Eclipse workbench, a Java-based IDE (Integrated Development Environment).</description>
	</item>
	<item>
		<title>XML-Based Documentation Using AurigaDoc</title>
		<link>http://tc.eserver.org/26318.html</link>
		<guid>http://tc.eserver.org/26318.html</guid>
		<description>A review of an XML-based documentation tool.</description>
	</item>
	<item>
		<title>How to Choose a Good Instructional Book about OpenOffice.org</title>
		<link>http://tc.eserver.org/26112.html</link>
		<guid>http://tc.eserver.org/26112.html</guid>
		<description>If the success of an open source project can be measured by the number of third-party books about it, then OpenOffice.org is thriving. Not only is OpenOffice.org represented by a dozen books and pieces of training material on Amazon.com, but interest in OpenOffice.org is widespread enough that each of the books is geared to a slightly different audience. This article gives an overview of four of the current OpenOffice.org books, ending with a suggestion of which to buy for your own needs.</description>
	</item>
	<item>
		<title>Read and Write DocBook XML Using OpenOffice.org</title>
		<link>http://tc.eserver.org/25930.html</link>
		<guid>http://tc.eserver.org/25930.html</guid>
		<description>The project goal is to explore the possibility of using OpenOffice.org as a WYSIWYG editor of XML content. The principle is to edit structured documents using styles. These styles are then transformed to XML tags on export.</description>
	</item>
	<item>
		<title>Cross-Referencing Step Numbers in Word</title>
		<link>http://tc.eserver.org/25081.html</link>
		<guid>http://tc.eserver.org/25081.html</guid>
		<description>If you are like most technical writers, your procedures have automatically numbered steps (whether in tables or text), Microsoft Word provides two relatively simple ways for you to cross-reference a step number.</description>
	</item>
	<item>
		<title>Creating Multimedia Hardware Procedures with ShowMe How</title>
		<link>http://tc.eserver.org/24250.html</link>
		<guid>http://tc.eserver.org/24250.html</guid>
		<description>Learning the correct steps to install or remove a computer component, such as a memory module, can involve, at best, hands-on instruction or, at worst, only written instructions. To increase the likelihood that customers and service personnel will be able to perform correctly the hardware service procedure for each fieldreplaceable component, Sun MicrosystemsTM now ships high-quality multimedia of removal and replacement procedures, called ShowMeTM How, on CD with each UltraTM Workstation and Enterprise Workgroup Server.</description>
	</item>
	<item>
		<title>RoboHelp Office v.3x: the Good, the Bad, and the Indifferent</title>
		<link>http://tc.eserver.org/23685.html</link>
		<guid>http://tc.eserver.org/23685.html</guid>
		<description>Overall, in my experience, writers and programmers prefer to use RoboHelp to create and maintain Help systems because the application has fewer issues with the Internet and programming platforms. In fact, for this latest version Of RoboHelp, I have only one minor complaint. Here is a summary of my findings.</description>
	</item>
	<item>
		<title>Technology and Management Issues in Implementing Online Documentation</title>
		<link>http://tc.eserver.org/21502.html</link>
		<guid>http://tc.eserver.org/21502.html</guid>
		<description>This workshop explores how traditionally trained technical communicators can help their companies make wise investments in authoring and delivery software for online documents, explore the potential&#xD;of technology currently available, and ensure that&#xD;their technology choices don&apos;t lead to dead ends.</description>
	</item>
	<item>
		<title>Software Usability and Documentation</title>
		<link>http://tc.eserver.org/21382.html</link>
		<guid>http://tc.eserver.org/21382.html</guid>
		<description>This article shows how a user-centred approach to software design can reduce the requirement for documentation. It lists Jakob Nielsen&apos;s usability heuristics, and for each one, shows how following the heuristic can reduce the requirement for user documentation.</description>
	</item>
	<item>
		<title>Documenting Entertainment Software: The Mixed Challenge of Simplicity and Sophistication</title>
		<link>http://tc.eserver.org/21025.html</link>
		<guid>http://tc.eserver.org/21025.html</guid>
		<description>The challenges of documenting entertainment software are in many ways the challenges of all technical communicators. We strive to make the interface intuitive&#xD;and the documentation interesting and easy-to-read.&#xD;Although the nature of the world of entertainment may&#xD;suggest that our task is simple, the breadth of our&#xD;audience and the depth of our goals makes it more&#xD;sophisticated than it looks. We must be as imaginative&#xD;as our users, recognize the emerging dimensions of&#xD;multimedia, and create with the constraints of low retail&#xD;costs, small teams, and fast-paced deadlines.</description>
	</item>
	<item>
		<title>From Good to Great—: The Finer Points of Writing User Documentation</title>
		<link>http://tc.eserver.org/21026.html</link>
		<guid>http://tc.eserver.org/21026.html</guid>
		<description>A few years ago, the NeXT user publications group was handed a&#xD;charter to create casual books with personality. We were also told to&#xD;condense the user documentation for an entire operating system and&#xD;several bundled applications into 300 pages. And of course we had&#xD;the top priority of creating accurate, complete, and easy-to-use&#xD;documentation. To our delight, these goals ended up being mutually&#xD;compatible. The keys? Task orientation, flat hierarchy, carefully&#xD;crafted page design, illustration, and a casual, intelligent tone. We&#xD;also broke some &apos;rules&apos;! (Caution: Some of the following material&#xD;may seem radical to seasoned traditionalists.)</description>
	</item>
	<item>
		<title>Publishing Documentation in Microsoft Word: Don&apos;t Do It!</title>
		<link>http://tc.eserver.org/20706.html</link>
		<guid>http://tc.eserver.org/20706.html</guid>
		<description>To save costs, many small businesses take the do-it-yourself route to publishing product and support documentation. The tool of choice is often Microsoft Word - after all, you probably already have a copy of it and know how to use it reasonably well. But while using Word to &lt;i&gt;develop&lt;/i&gt; your materials is an acceptable choice, using it to &lt;i&gt;publish&lt;/i&gt; documentation is not! Read on to learn some of Word&apos;s shortcomings as a publishing method, and what alternatives are available.</description>
	</item>
	<item>
		<title>What It Takes to Document America’s Best-Selling Tax Software</title>
		<link>http://tc.eserver.org/20452.html</link>
		<guid>http://tc.eserver.org/20452.html</guid>
		<description>Because both the TurboTax Deluxe software program and the federal tax code are redesigned every year,&#xD;preparing TurboTax Deluxe’s raft of documentation demands a management approach that emphasizes planning, teamwork, task dependencies, and an elusive&#xD;mix offlexibility and clearly defined project ownership.</description>
	</item>
	<item>
		<title>A Document Management Case Study: QLD Dept of Housing</title>
		<link>http://tc.eserver.org/20306.html</link>
		<guid>http://tc.eserver.org/20306.html</guid>
		<description>How a new spin on document management software helped revolutionise customer service at the Queensland Department of Housing.</description>
	</item>
	<item>
		<title>Applying Computer Analysis and Design Techniques to Document Component-Based Software</title>
		<link>http://tc.eserver.org/20275.html</link>
		<guid>http://tc.eserver.org/20275.html</guid>
		<description>Facing the challenges involved in developing documentation for component-based software (for example, object-oriented technology, intelligent agents, and distributed computing) requires a documentation&#xD;strategy based on the same processes and methodologies&#xD;used by such technologies. These strategies need to be&#xD;adapted to meet documentation, rather than coding&#xD;needs. Developing this strategy now, as component-based&#xD;technology is still maturing, will help technical&#xD;communicators keep pace.</description>
	</item>
	<item>
		<title>What Is RoboHelp?</title>
		<link>http://tc.eserver.org/20035.html</link>
		<guid>http://tc.eserver.org/20035.html</guid>
		<description>RoboHelp is an authoring tool sold by eHelp Corporation (formerly Blue Sky Software). In an easy &apos;WYSIWYG&apos; format, it allows you to organize information and create pathways and interactive links so a user can find desired or necessary information (and the user can do so in a non-linear intuitive way that is helpful to learning).</description>
	</item>
	<item>
		<title>Going Online: Selecting the Right Tool</title>
		<link>http://tc.eserver.org/19831.html</link>
		<guid>http://tc.eserver.org/19831.html</guid>
		<description>There are numerous tools that you can use to create online documentation. However, each tool has its strengths and&#xD;weaknesses, and each is more appropriate for some types of information than others. This workshop explores many&#xD;issues of online documentation tools: Why go beyond Windows&#xD;Help? Which is better: HTML or Adobe Acrobat?&#xD;What tools support cross-platform presentation? When&#xD;should you use Workgroup tools such as Lotus Notes or&#xD;Folio? When does SGML make sense? How to utilize a!ocument&#xD;databases? When to use Management tools? Real&#xD;examples developed using these tools will be given throughout&#xD;the session. Participants will leave with a clear understanding&#xD;of the pros and cons of each.</description>
	</item>
	<item>
		<title>Implications for Writers Documenting Object-Oriented Projects</title>
		<link>http://tc.eserver.org/19803.html</link>
		<guid>http://tc.eserver.org/19803.html</guid>
		<description>Object-oriented (OO) projects bring with them new&#xD;technology and new processes. While programmers&#xD;focus on the OO methodologies governing design&#xD;and implementation of program code, writers must&#xD;struggle to adapt to a very different kind of development&#xD;cycle. To avoid chaos, development teams&#xD;must explicitly define their processes from the start.</description>
	</item>
	<item>
		<title>Ten Misconceptions about Software Documentation</title>
		<link>http://tc.eserver.org/15210.html</link>
		<guid>http://tc.eserver.org/15210.html</guid>
		<description>Presents ten misconceptions about software documentation that may have contributed to the persistence of poor documentation.</description>
	</item>
	<item>
		<title>Help Authoring Tools: a Comparison</title>
		<link>http://tc.eserver.org/14962.html</link>
		<guid>http://tc.eserver.org/14962.html</guid>
		<description>The purpose of this article is to give a rough evaluation of the various help authoring packages.</description>
	</item>
	<item>
		<title>&quot;Try Before You Buy&quot; Help Authoring</title>
		<link>http://tc.eserver.org/14963.html</link>
		<guid>http://tc.eserver.org/14963.html</guid>
		<description>Help authoring systems can prove to be a fairly expensive purchase especially for the freelance writer. Luckily, most publishers allow you to try out demonstration versions of their software before you commit yourself to buying. As well as demos of commercial applications, you can find some very high quality shareware and freeware products. </description>
	</item>
	<item>
		<title>Using RoboHelp to Develop a Simple Web-Based Tutorial</title>
		<link>http://tc.eserver.org/10702.html</link>
		<guid>http://tc.eserver.org/10702.html</guid>
		<description>Many technical communicators are tasked with converting user manuals and other documentation written in Adobe FrameMaker into online help using eHelp (formerly Blue Sky) RoboHelp. The problems they face concern not only going from FrameMaker to RoboHelp but also how to put the content in a form that is effective for online help. The solution is not difficult, provided the writer follows a methodical approach.</description>
	</item>
	<item>
		<title>Screen Captures in Software Documentation</title>
		<link>http://tc.eserver.org/10363.html</link>
		<guid>http://tc.eserver.org/10363.html</guid>
		<description>While screen captures are the most widely used illustrations in manuals, there is almost no literature on their role and design. In this paper we draw together practice, theory and empirical research to advance a taxonomy that identifies these roles and designs. We suggest that screen captures in software documentation can help the user to switch attention, develop a mental model of the program, verify screen states, and identify and locate window elements and objects. Four important design areas (coverage, positioning, size, and cueing) are distinguished and empirical findings discussed. Research has substantiated the claim that screen captures speed up task completion, but others have yet to be proven. We believe that a more refined approach, afforded by the taxonomy, is likely to improve practice and research, and yield strong evidence supporting the use of screen captures in software documentation.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/Software.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>