If you expect to stay with traditional tools, you should understand what they are, as well as what they’re capable of doing. There are really three types of traditional tools: word processing tools, page layout tools, and hybrids that combine the functionality (to some degree) of both word processor and page layout tools.

If XML is part of your authoring environment, you have the option of using structured editors as your authoring tool. Structured editors enforce the structure of content, typically based on a model such as a DTD. (For more information on structured authoring, see Chapter 14, “The role of XML.”) There are XML-aware tools (traditional tools with integrated XML), Native XML/SGML editors (editors that work natively in XML/SGML), and other editors that enforce structure in different ways.

There are four types of structured editors:

Given that people do not always accept change easily, there can be an advantage to sticking with the tools they know. The main advantage to traditional word processing tools is that they are familiar to most employees. Tools such as Word are very common on the corporate desktop and authors have become accustomed to their look and their functionality.

Structured authoring tools, on the other hand, have been around for many years, but have not gained the same popularity. The tools with embedded support have a familiar interface, but the technology and the technological concepts behind the interface are new. For other XML tools, both the interface and the concepts will be new to authors.

If you are dealing with casual, non-technical authors, there may be an advantage in sticking with a traditional tool.

Traditional authoring tools are typically more suitable for the lowest common denominator. That is, they are easy for even casual authors to use. That is not the case with most structured editors. In selecting a structured editor, a key factor to consider is how much of the underlying technology is exposed to authors. Can users choose the level of complexity presented to them?

Of course, if you do choose XML, you have additional options. Because XML is an application-independent form of markup, you can select different authoring tools for different groups of authors in your organization. Authors with very simple authoring tasks can use an editor with simple editing functionality. Authors who perform more complex authoring tasks need a more capable tool. Structured editors range from simple file editing tools (that is, tools that are used for editing a file but have no capacity for book building) to full function tools that include all the usual capabilities of standard authoring tools.

Traditional tools tend to be mature tools. They all have things that they do well or not so well, but they also have very rich and complete functionality, including capabilities, such as spelling and grammar checkers, autocorrect and autoinput, change tracking, and macros.

Tools such as spell checkers and grammar checkers are often taken for granted until they are not available. A non-traditional tool may be less mature and may not include the functionality that authors have become accustomed to. Even though such items as spelling and grammar checkers may not be on your selection criteria, they may be critical for your authors to have.

Some structured authoring tools have reached the same level of maturity as traditional word processors; others have not. Many of the full-function tools include spell checkers, grammar checkers, table functions, math functions, table of contents tools, index tools, and others that simplify the authoring task.

Word processing tools are the most mature of the traditional tools. They started life as tools for letters, memos, and short reports. Longer documents—not the original focus of the tools—need what are traditionally known as book-building tools. Book-building tools generate:

Most, if not all, of the traditional tools now have book-building capabilities, which is both good and bad. They started off as simple editors, but the book building tools have been added on, and their effectiveness can be debated. There are exceptions: products that were built specifically as long document tools. As a result, their book building functions work very well.

As noted previously, structured editors may or may not support book building; they range from simple file editing tools (that is, tools used for editing a file, but with no capacity for book building) to full-function tools that include all the usual capabilities of standard authoring tools. The full-function tools include spell checkers, grammar checkers, table functions, math functions, table of content tools, index tools, and so on.

When it comes to book building needs, structured editors offer an additional advantage. With XML-based authoring, it is easy to move book building out of the authors’ hands and automate the generation of TOCs, indices, and so on. You don’t need TOC or list functionality; it can be provided for in style sheets.

The biggest disadvantage to traditional word processing and page layout tools is that they offer too much flexibility. They do not prevent authors from creating new styles or applying formatting to suit their own views of how information should look on the page. The result is inconsistent formatting and style names. There is also no built-in functionality to ensure that authors include all the elements required for the information product they are writing. In other words, there is nothing to enforce structure. Style names only imply structure. Users can easily ignore the styles and format directly. The documents might all look alike on the surface, but may not look alike “under the covers,” with authors manually creating the look and feel rather than using consistent style tags. This is inefficient for authors and has a major negative impact on conversion to other formats; content that is not consistently formatted (tagged) cannot be automatically converted to another format. It requires manual cleanup. An alternative is to enforce formatting and structure through policy and procedure (editorial or review), but such reviews are never 100% effective. The result is inconsistency. Inconsistency means unpredictability, which is a killer for reuse and multi-channel output.

Structured editors do not have the same problems with format. As the name suggests, structured editors focus on the structure of the document. Most structured editors enable users to attach a style sheet to documents, which serves primarily to provide a certain comfort level for authors. The obvious advantage to structured editors is that they use XML, with great advantages for reuse (see Chapter 14. More important, structured editors are capable of reading and enforcing a DTD or Schema. At their simplest, structured editors allow authors to validate a document’s structure: they identify any structural errors in the document, including when elements are not allowed or when they are missing.

Some editors do not allow authors to insert invalid elements of structure. For example, they would not allow authors to insert a table in a title. The most capable tools provide authors with drop-down lists or menus of elements that are valid in the document. As authors move the cursor around the document, from element to element, the drop-down list changes to show the valid elements. This prevents authors from entering tags where they are not allowed. This type of structured editor does not allow authors to make structural mistakes.

Traditional tools make it easy for authors to make documents look good, and in doing so, they have turned authors into desktop publishers. But from the perspective of reuse, this is not a good thing for many reasons.

Word processors and desktop publishing tools helped to make documents very attractive and, potentially, more usable. Authors enter the characters that form the content, then select them and apply the formatting. For reuse, you need to remove this formatting to make the content output-independent, then apply format that is appropriate to each intended use. Stripping and reapplying formatting always requires correction by hand or complicated scripting.

XML does not have this problem. The presentation information (styles) are maintained in separate files that can then be associated with the document when it is published or used.

A key factor to consider when choosing an authoring tool is conversion. The current pattern of delivery for information is that the same information is delivered in different formats. To move information from one format to the other, the materials must be converted. Ideally, the conversion should be automated so it can be done “on the fly.” If you plan to share content authored in many tools, it will be necessary to convert the content from each of the authoring tools into a common format that can be managed and then converted back to another format for reuse.

All the traditional tools have some sort of conversion capability. Some have “save as” functionality, which allows you to save the current document in other formats. The conversion utility converts the native formatting codes into the equivalent codes in the target output format. For example, most (if not all) word processors allow you to save documents as HTML. However, what you get is HTML with formatting characteristics that are more suited for paper output than browser display. The output is not usable in a browser.

Some traditional authoring tools use third-party applications to provide style conversions. These types of conversion tools tend to place more emphasis on defined styles in the document, specifically on style names. They enable you to define format transformations based on the names of styles in the source document. In these transformations, you can ignore the paper-based formatting and apply format characteristics that are better suited to your output medium.

Traditional authoring tools offer no real control over styles. Authors can create, change, or delete styles at will. This is a major problem for conversion. It is very difficult to automate conversion if you cannot predict the styles used in source materials. Where styles and structures in source information are inconsistent, conversion must be done manually. Manual conversion eliminates the option of automatic reuse. For any large enterprise, this is not acceptable: It is simply too expensive.

For conversion, there is a clear advantage to XML tools. The separation of content and format is invaluable. To convert XML content to another format requires only a new stylesheet.

If you need to assemble output documents from pieces of content, whether on the fly or as static output documents, structured authoring has a clear advantage. XML is very easy to assemble and reconfigure into new outputs (see Chapter 14).

The effectiveness of traditional word processors is entirely dependent on the ability of authors to create consistently formatted and tagged files. Files can be reassembled, but you need extensive programming support to build the utilities to strip out and reapply formatting.

Traditional tools are already in place in most enterprises. They have been purchased, installed on the desktop, and have been in use for many years. Users have templates in place, and the IT infrastructures are in place to support the tools on the desktop. Extensive training is available for authors not already trained in the use of the tools. In addition, there are individuals who are experts in their use. In a corporate climate where the bottom line is carefully monitored, a solution that uses tools that have already been paid for can be very difficult to argue against.

New tools and technologies do not have the same immediate support. Changing enterprise tools can mean you need to build all the support infrastructure. But, the additional implementation overhead is not necessarily seen as a detriment when the new technology adds new functionality such as structure.

See Chapter 13 for the general questions that you should ask of vendors.

Although authors can create content, save the content, then check the file(s) into a content management system, it is preferable to have the authoring tools directly integrated into the content management system. This means that when authors select File, Open, the authoring tool automatically goes to the content management system to select content. When authors do a File, Save, the content is automatically saved to the content management system and any version control information is gathered. In addition, if your organization has decided to use systematic reuse, it is important that the content be automatically populated to the document open in the authoring tool.