Structured document — research review

(Summary for a departmental review)

Structured documents are those which have a consistent formation composed of recurring patterns like chapter–section–subsection, poem–stanza–line, page–section–article, or article–clause–subclause–schedule. They don't have to be regular, but there must be evidence of a pattern.

Common examples are books, articles, reports, journals, white papers, legislation, contracts, essays, leaflets, letters, manuals, calendars, blogs, wikis, web sites, newletters…and theses. Humans have been creating documents like this for over 5,500 years.

Markup

Software techniques known as `generic markup' have existed for decades for increasing the reliability, accuracy, and durability of what authors write, but the programs that use it were designed for technical writing experts and document engineers rather than for the business, academic, or professional writer. These programs expect the writer to know and understand pointy brackets, curly braces, and other odd characters, and all the special syntax and rules that go with them — but they will produce solidly reliable, stable, accurate, and reusable documents which cannot be obsoleted by commercial pressures.

At the other end of the spectrum there are wordprocessors, which claim to be fantastically easy to use, but which have no way at all of letting the author create a structured document. Because their chief concern is appearance, not structure, they can make a document look structured, but without actually being so. Their chief attraction is that they allow the author to put anything anywere. Their chief disadvantage is that they allow the author to put anything anywere, without any regard to sense or context.

A very few programs attempt to bridge this gap, such as LyX and XOpus, but they either fall at the first fence of usability in being non-obvious, or they are only usable in restricted environments such as inside a web browser.

Objectives

This research tries to identify how structured-document techniques can be made more usable by authors — whether the software can be adapted to the needs of the writer, or whether the writers adapt themselves to the demands of the software.

Methodology and initial findings

• We created a baseline for the information-set by interviewing 20 experts, mostly consultants or developers in the document engineering field. They were asked what problems and benefits they saw when introducing or developing structured-document techniques for a client.

• An analysis was made of the features of structured-document techniques and the implementation of those features in 30 existing software products. The effort required to use them was measured using the depth of items in the menus and the way in which they were labelled.

• From an study of 5,500 user requests to discussion forums looking for suitable software we isolated some 400 which we categorised according to what the user was asking for, leaving aside those which were too general and those which were specific to a single product.

• A sample survey of existing authors was done to identify the methods they used to perform a specific set of writing and editing tasks, which we could compare with what the software actually provided. The data allowed us to isolate a dozen features of existing software which writers identify as hindrances.

From this we identified a list of the interface items which appeared to contribute most to the mismatch between the authors' requirements and expectations of the software behaviour, and how the software actually performed. Each item was then compared with its function (which by definition it was not performing optimally), to see what changes could be made to improve it, using User-Centred Design principles.

---

As it is not practicable to write an entire structured-document editor to test the proposed changes, we will use the Paper Prototyping methodology. This involves a sequence of printed screen mockups of an editor in mid-document, which are shown to subjects who are given a task such as `Create a new section'. They are asked to indicate what they would click on to do this, and are shown the next `screen' in sequence.

This provides a record of what the subjects expect the interface to do, as well as an indication of the visibility and obviousness of the changes to the interface items.