Of all the technical writing tools I’ve used over the years, Epic Editor was probably the most impressive, especially when it came to doing tech documents that involved DocBook and Dita.

It was difficult to learn – no point pretending otherwise – but once I got the hang of it, I used it non-stop for over 2 years. Then I switched companies are haven’t had the opportunity to use it again. With that in mind, here is a brief intro to EPIC Editor, Ivan’s favorite XML Authoring Software!
[ad]

What type of document types does EPIC Editor support?

First up, let’s define a document type. According to EPIC it “refers to a collection of files that together create an application for creating and publishing documents.”

Examples of different document types include:

• Schema or DTD
• Stylesheet(s)
• Sample and template instances
• Configuration files
• Programming files that further customize the authoring or publishing environment

What document types are available in EPIC?

EPIC Editor supports the following types:

ATI XML DocBook — version of the DocBook DTD extended to provide profiling and equation editing.

• ATI Simplified XML DocBook Article — extended to provide profiling and equation editing.
• ATI Very Simple XML DocBook Article is a schema-based (.xsd) XML document type based on the ATI Simple XML DocBook Article. This document type has no DTD.
• ATI Catalog is an Arbortext-developed document type, based on DocBook 4.0, for catalog applications.
• Article is an article format based on ISO 12083.
• DITA Concept, Reference, Task, and Topic — the primary categories used for technical documentation.
• Book – book format based on ISO 12083.
• DocBook V4.0 – used for computer software documentation.
• News Release – format for preparing news releases.
• Correspondence – for business letter or memo format with several styles to choose from.
• General Purpose Document  - reports, books, and other types of documents.
• ATI-MIL-M-38784C – CALS standard document type.
• HTML V4.01 – for publishing information on the web.
• XHTML V1.0.
• Free-form XML – for creating valid XML documents that do not have schema or DTD declarations.
• ASCII  - standard unformatted text character set.

How does it work?

The interface is simple and lets you get at the XML tags very easily.

This screenshot shows the results of a test on the clarity of the document (ie its readability) and the number of words.

Next is the toolbar.

This offers a range of features that should keep most all Technical Writers satisfied if they want to develop nice, compliant XML and DocBooks.

Note that you can create tags, split sections, insert tags, and check their integrity.

EPIC Editor won’t let you add tags if they are in the wrong sequence. It this sense it can be very unforgiving – but it is simply trying to retain the integrity of the underlying code. Once you understand how XML works, it gets much more intuitive.

You can also import text files from your PC and add them to the document set.

Once you have the document ready, you can compile it to Windows Help or transform it to:

• ASCII
• DITA
• Docbook source
• XHTML

You can also add entities and prolog definitions, but this is more for advanced users.

Tip: you can also select part of the text and validate it only.

Here you can insert markups into the content, usually as tags.

Preferences

You can configure it in different ways. For example, you can ask it to show Attributes, Comments, and Tag prompts. Whichever suits your style of working.

This gives you an idea of how it checks the xml code. Work your way through the errors and fix each one after reviewing it.

Like I said, I haven’t used this for a while. Let me know if you’ve used it recently and seen any changes.

How does it compare to other technical writing tools you have used?
[ad]

In a recent survey, Scriptorium Publishing found that a majority of technical writers will be working in a structured authoring environment by 2010.

Structured authoring is a publishing workflow that defines and automatically enforces consistent organization of information. Implementations are generally based on Extensible Markup Language (XML).

[ad] 

“Most of our consulting projects involve XML,” said Sarah O’Keefe, President, Scriptorium Publishing. “This survey shows that our anecdotal experiences, such as the importance of change management, match the industry situation.”

The survey, conducted in early 2009, had more than 600 responses.

Participants cited content reuse, document consistency, and cost/effort of developing content as the primary factors driving them into structured authoring.

The Darwin Information Typing Architecture (DITA) standard was the dominant standard employed.

40 percent of existing implementations and approximately 60 percent of in-progress and planned implementations are based on DITA.

Implementations were generally quite successful.

90 percent of respondents with completed implementations reported that they had improved document consistency.

86 percent were successful in content reuse, and 70 percent reduced the cost and effort of developing content.

When asked about implementation problems, 37 percent cited difficulties with project management, including “failure to plan” and “insufficient analysis.”

“The survey validates our current methodology,” said O’Keefe. “We establish goals and metrics long before any technical work begins.”

Change management was a significant concern. Of the 16 percent who did not plan to implement structured authoring, one third cited the inability of the staff to adjust to a new authoring environment as a factor.

Staff turnover was also a problem for nearly 30 percent of past and nearly 20 percent of current implementations.

The survey data indicates that private, customized training improves outcomes by increasing the percentages of respondents who achieved their goals. Interestingly, private training also correlated with change resistance.

The 56-page report is available at  www.scriptorium.com