View Edit Attributes History Attach Print
|Research / SummarySoFar|
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.
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.
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
The principal finding was that the existing software required such extensive training or customisation that cost was a major factor.
This showed that virtually all the software implements approximately the same set of features, so that the differences are largely in the menu placement, labelling, and behaviour.
Unsurprisingly, WYSIWYG came top, closely followed by `it must be free', and that it must be `easy to use' — meaning either `obvious' or `Word-like'.
Problems with WYSIWYG headed the list, followed by formatting, moving blocks of text around, inserting new material, and the use of keyboard shortcuts (and a long tail of others).
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.
This page was last modified on May 23, 2011, at 09:16 PM