Only You Can Make XML Editing Easier

by Lisa Bos

Mar 2003

The promise of increased productivity is one of the primary reasons publishers decide to invest in XML-based content management. But in our experience, publishers often pay too little attention to the area of the system where most people spend most of their time, and where ease of use and speed are therefore especially important—the XML editing tool.

XML editor customizations fall through the cracks for several reasons:

Before the system's been built, it's hard to define specific system requirements related to increased efficiency/proficiency through an editing tool. Therefore, there are no corresponding tasks in the project plan.
People who don't actually use XML editors assume that you basically just have to plug them in and you're done—the user just needs to become familiar with the tool. This assumption is based on experience with tools like Microsoft Word, and it's a false one. XML editors need to be customized to your environment.
Neither the project team nor the system's users realize that there is often significant opportunity for automating repetitive tasks within an XML editor (e.g., link checking or tagging inline content like part numbers or drug names).

A Little Background

To date, XML editors have proven to be fundamentally different tools than word processors. This is true both in terms of set up (DTDs or schemas must be made available and stylesheets must be developed) and in terms of user experience (users must work within the defined structure from the first character typed). The two commercial tools most widely used by editors and authors (Corel's XMetaL and Arbortext's Epic) have come a long way in terms of usability, but working with them can still feel awkward if you are expecting an experience similar to Word.

This awkwardness translates into taking longer to do some tasks than would be expected beforehand. Sometimes this awkwardness relates directly to the extra value that you get out of more intelligently tagged content and cannot be avoided (although it should certainly be accounted for when considering staffing needs). But in many cases the efficiency impact of this awkwardness can be reduced or avoided altogether through thoughtful DTD or schema design and through customization of the selected tool.

Specific Suggestions to Maximize Productivity

1. Use an XML editor only if you really need to. If your documents are relatively simple in structure and don't have a lot of inline elements with attributes, consider using a word processor, or even custom forms. Regardless, no choice should simply be assumed. Open up the topic for debate among the interested parties.

Make sure this debate includes discussion about how the XML editor fits into your workflow, and of whether it is reasonable to expect your users to take on the extra effort often associated with using an XML editor. The answer will be different for every kind of content and every publisher. If content is developed externally and converted to XML automatically, the time spent in the editing tool might be minimal and so the choice won't have much impact. In other cases, you might decide that separate groups should be responsible for writing versus XML tagging, with the writing being done in a word processor and the "clean up" in the XML editor. If the content is complex and must conform to a rigid outline, you might decide that the authors themselves must become proficient in using the XML editor. Regardless, consider all the factors before you plan for editing tool customizations and training.

A corollary to this suggestion is that incorporating an alternative type of editing tool (like Word) brings plenty of its own issues. If using a word processor or forms is an option, then you must determine whether the amount of development effort required to ensure correct and valid XML is offset by the time savings and other benefits of using that tool as compared with an XML editor. (Of course, these variables could be affected drastically by the next version of Word, which is said to include full-blown XML editing capabilities. We are very hopeful, but not holding our breath either.)

2. Understand that a complex DTD/schema translates into a complex XML editing environment.

For example: Layers of structural tagging in which there are required subelements often cause user frustration. Many DTDs support multiple heading levels through a model like this:

<section>
<title>This is the title</title>
<paragraph>A paragraph</paragraph>
</section>

If the <title> is required, then inserting the <section> around a group of existing paragraphs in an XML editor can require the user to perform a series of unintuitive steps. If the structural layer (<section>) is absolutely necessary, then help your users with macros for manipulating them, or make the title optional. If they aren't really needed, drop them.

This can lead to contentious debates among long-time SGML and XML developers. Structural elements like <section> group related content together and are typically considered good practice in XML. It's often easier to write software to process content (e.g., XSLT stylesheets) if there are structural elements like <section>. However, equally often there is almost no likelihood of needing to process or format the contents of one section level differently from another, but the DTD designer still has a strong preference to use them. Instead, we suggest taking a lesson from the success of HTML with Cascading Stylesheets, which, when well-applied, uses a combination of structure and "flat" tagging that is highly effective. It's worth noting that the conversion of legacy content and the use of non-XML editing tools are also made easier by limiting the number of structural tagging layers.

3. Work with users to identify a baseline set of customizations. Don't expect this requirements process to happen at the same time you develop the rest of your system requirements. Instead, you should first develop your DTDs/schemas and create a simple environment for using them with the selected editor. Have a small group of users mimic their day-to-day authoring and editing tasks using the new editing tool. Through that process, you should be able to identify needed customizations. Ideally, someone experienced in the use of the specific XML editor should facilitate this process. They will know the likely pain points to explore, and will point out basic needs (like having a keyboard shortcut for applying emphasis tags like <bold>) you might not think to include.

4. Schedule acceptance testing of the XML editor customizations. Certainly, the customizations defined during requirements analysis should be tested during the execution of your larger testing plan, but we suggest you find an opportunity to involve a much wider audience and to respond to their concerns where appropriate. If you are planning a parallel run of the new system along with the existing system, then that might be a good time. If not, this "testing" might be an aspect of the first few weeks your new system is live. Regardless of the timing, someone who understands the authoring/editing process as well as the selected tool should observe users as they work, looking for unnecessarily difficult tasks that might be improved through customizations. During this period, be sure to set the expectation with users that the goal is to increase productivity, and that the value of each requested change will be weighed against the effort to implement it.

In addition to addressing short-term issues, this activity can help users understand what types of inefficiencies or repetitive tasks it might be possible to reduce through further customizations. In our experience, many users of XML editors simply live with inefficiency because they don't know there's an alternative.

5. Schedule real training prior to system roll out. Depending on the complexity of your content and system and on the experience of your users, this training could take anywhere from 15 minutes to several days. The time invested is well worth the pay off.

6. Assign ownership to a specific person. For particularly complex environments, this might be a software developer. But in many cases, the best and most motivated person is actually part of the editorial or production team that is using the tool on a daily basis.

Finally, while you shouldn't skip over the step of tailoring the XML editor to your environment, you should also be aware that customizing the currently available XML editors is less work than you might think. Sure, some specific customizations might be especially complicated, but in many cases a change that represents significant improvement from your users' perspective might take no more than a few hours or even minutes to implement. This is one of the many areas in which XML pays off through easier automation—take advantage of it!