Schema selection and design

As observed earlier, it is important that the schema is carefully designed to minimize confusion and inconsistency in the markup. If an existing schema is used, it may be necessary to customize it to meet these requirements. Some schema attempt to provide elements to meet a wide range of possible circumstances. If these are not absolutely necessary in your application, they should be removed. Otherwise, they will confuse writers, make it harder for them to recognize the common markup patterns, and make it difficult to provide predictable behaviour in interface commands.

Ideally, the schema should be the simplest model that will create the desired markup structure. Most documents conform to very standard patterns for section/clause, paragraph and list structures. Ideally, the schema should make it easy for the writer to understand how these work. If the interface is then designed carefully, the writer won't really need to know the finer points of the schema rules until they are ready to learn them.

Next valid location element insertion

Next valid location insertion allows the writer to insert markup structures (elements) using a simple command without having to find the valid location first. Taking DocBook as an example, the writer may have created a section with one or more para elements. The insertion point is after the period at the end of the last para. The writer now wants to create a new section after the current section. The writer should be able to initiate an “insert section” command from a keyboard shortcut or other command to insert the new section without having to find the valid location for the section element. The application should take care of this.

Effective use of this strategy requires that the schema use tight content models. If there are many possible valid locations for the section element, constraints must be created in the customization code, thereby making it more expensive to develop. These constraints operate as a pseudo schema change. Ideally, the constraints should be imposed by the schema.

Next valid location element insertion commands can be made more powerful if they recognize shield elements. For example a para may be followed by a blockquote element. If the insertion point is in the para and the writer fires a command to insert a new para after, it may be inserted inside the blockquote. This may not be desired. Ideally, the application should allow the blockquote to be excluded from the valid locations in that circumstance. Instead, the application might only insert a para inside blockquote if the insertion point is already inside the blockquote. These rules should be carefully planned.

Context driven element insertion commands

In word processor software, writers are accustomed to pressing the Enter key to create new paragraphs and list items etc. In a word processor, this is achieved through chaining styles. The limitation of this is that the sequence can never change according to context.

In a structured schema with some XML editors, it is possible to define different behaviour for element insertion commands according to the context. It may even be possible to use the text characters adjacent to the insertion point to further refine context rules. Thus, pressing Enter after a list item that is terminated by a semi colon may create a new list item while pressing Enter after one that is terminated by a period may create a new paragraph after the list.

These rules must be based on conventions that are convenient to the writers who will use the application.

Templates

The use of templates is a simple way to create the major structures in a new document, just as with word processor documents. Very often, the major structural divisions in a document are only created once. If they are included in the template, the writer does not have to bother about creating them and it is probably not necessary to create specific interface commands for them.

Pre-formed structures

Pre-formed structures are packaged element structures inserted on a single command. If it is common to insert several nested elements before typing content, a template with those structures can be created and inserted by an interface command. Often these are context dependant so use of context rules may be helpful to make this feature work well. For example, in one context a command may insert a section with a para element and in another it may insert just the section element.

Data entry forms

In most XML editors it is possible to create forms to enter element or attribute data. These can be very helpful for graphics, metadata, cross references and tables.

Keyboard shortcuts

Keyboard shortcuts can be defined to execute common element insertion or other commands. The underlying action maybe to insert pre-formed structures at the next valid location, according to a defined context. In this way, a great deal of markup can be inserted very easily without the writer having to break concentration.

Menu items

Pull down menus and toolbar buttons should be used to organize the more common and the less common commands so that the main interface is not overloaded.

Element selection utilities

Writers frequently need to select elements, cut them and paste them into a new location. Some editors provide keyboard shortcuts to allow the writer to progressively select containing elements. However, for common actions, specific commands may be created to select specific elements and speed up the writer's work. These are more accurate because the writer knows exactly which elements are selected.

Custom utilities

In most applications writers have to perform common editing commands. They may need to insert elements by pasting copied content in particular contexts. Commands can be created to transform markup and to control the destination of pasted content so the writer does not have to find the valid location in Tags On View before pasting.

Utilities can be created to assist writers to create cross references so they don't have to write in ID values at targets.

Reduce effort training new writers

One of the biggest hurdles for writers new to XML is to learn about XML and the rules of the schema. The aim of an effective customization should be to reduce the interface to a small set of commands that enable writers to create common markup structures without being concerned about the schema rules. Naturally, writers must understand the basic patterns and rules but these only have to be understood at a high level. In this way, writers can begin work quickly without even seeing XML markup. This builds confidence and allows writers to learn the detail as it is needed. Over time they will build up a good understanding of the schema.

Improve markup consistency and reduce editorial costs

The processes described will ensure that the schema and the user interface are coordinated. Redundant elements should be removed and excessively loose content models tightened. When writers work through defined interface commands, the XML markup created will be more consistent than if they must choose elements and contexts through the standard interface components.

Improved markup accuracy at source means fewer problems and lower rectification costs at later stages in the content life cycle.

Improve writer productivity

Standard interfaces in XML editors do not allow writers to work smoothly. They must frequently stop to perform complex or fiddly element selection and insertion actions in Tags On or Structure Views. A more usable interface will enable writers to work more productively.