A simple and general scheme is described that permits multiple authors to collaborate on certain sorts of hypermedia document. The scheme separates content, page design, and site structure. Each author can work in a small space, and therefore have higher quality control over their product. By allowing multiple authors, the workload is divided.
A prototype system has been implemented (in Java) and shows the scheme is feasible, and that it scales up to arbitrary size sites. The prototype suggests many profitable developments.
Authoring hypermedia documents is hard, because they are large, integrate many media, and have hypertext links and associated scripts or applets. The various media have to be kept in track of each other, creating a combinatorial explosion of version control problems; and unlike conventional media, the various components that should remain consistent need not, and sometimes cannot, all be visible simultaneously. When a hypermedia document is authored, every plan of the author can be represented in more than one place (for example, to be elaborated at the other end of a link), and each alternative development of a thought multiplies the size of the authoring problem. Very few links soon create more potential developments than can be maintained by an unaided author. Revision and maintenance of hypermedia documents further requires an author to work locally in a structure that they may not be fully conversant with. In short, hypermedia authoring is impossible do well without automated support. To provide quality control, tools have to be used.
Unfortunately, current tools have several limitations (in varying degrees) with respect to quality control:
What is required is a distributed database that has a WYSIWYG user interface, and which does not centralise structural decisions, allowing distributed authors to control their parts of the structure. This would enable groups of authors to share the authoring burden, yet use database techniques to do quality control, for instance to provide a consistent navigation structure.
This paper describes a scheme that supports distributed web authoring. It allows many authors to write single pages or even large sites and unite them into a coherent site. Authors may use and share page layout designs, and these can be applied consistently. Currently the prototype system supports the design of static documents (composed of pages as sophisticated as any available HTML editors permit), but this is not a conceptual limitation of the approach. The purpose of this paper is to describe how the system works, specifically to show how powerful a simple scheme can be for creating well-organised sites out of distributed authoring contributions. We also show that the idea is productive as a tool design concept and lends itself to many extensions.
Our system is implemented as a Java program. It is run rather like a compiler, compiling 'source files' (original authored pages) anywhere in the world to 'object files,' which are given a consistent style and linkage by the compiler. We will refer to the set of object pages as a 'site'; typically a site will conceptually be a single document, in the conventional sense of having a coherent structure and message, but this is not required.
The compiler could be distributed, and the object files could be generated on demand. These, of course, are superficial design alternatives, and we will not discuss them further here. For clarity in this paper, we will refer to the person running the compiler as the 'user' and other contributors (possibly including the compiler user) writing web pages as 'authors.'
The compiler works in several phases:
As so far described, the compiler is doing no more than collecting and checking distributed web pages. What is novel is yet to be described.
All source pages can contain directives to the compiler, and these control how the compiler constructs and organises the object pages into a coherent site.
Any text set between stars is treated as compiler directives; this allows the directives to be written conveniently using any HTML page editor. (A syntax that was SGML compliant would require flexible HTML editors, and would probably be harder to edit in a WYSIWYG editor.) The directives can specify:
*before* and *after* can be
followed by a link to a page (using HTML links as usual), and to specify that
the current page should be before or after the other pages.*sequence* specifies a sequence
of pages (not necessarily including the current page), and gives their
before/after relation.*in* and *contains*
for relative positioning to the current page, and *nest*
for nesting arbitrary pages.The directives before/after/contains/in are followed by HTML
links. Thus, writing
*in* <a href="xxx">yyy</a>
means 'put this page inside page xxx (given as a HTML link),' and it is
also equivalent to '*nest* <a href="xxx">yyy</a>
me*/nest*,' where me is an explicit
link to the current page.
The directives before/after/contains/in allow various forms of
web structure to be specified. Thus, Sano (1996)
recommends 'group' and 'hierarchy' for organising webs. Our before/after
do groups; contains/in do hierarchy. We could add many other
directives, but our purpose here is to explore the practicality of the scheme,
rather than to immediately add many features that would disguise any fundamental
limitations.
Suppose the compiler processes at least two of the following directives in any pages:
*sequence* a c */sequence* *sequence* b c */sequence* *sequence* a b */sequence*
Then a solution to these constraints is the order a, b, c
(if only *sequence*
a c */sequence* and *sequence* b
c */sequence* were processed, the compiler could chose the
alternative solution b,
a,
c, since the sequencing of a and b has not been
specified by an author; presumably the authors do not mind if they do not say
so). There are many ways of achieving the same result. The same solution would
obtain from compiling page b if it contained:
*after* a *before* c
The same sequence could also have been specified explicitly as *sequence*
a b c */sequence*, and this could have been placed in any
page: a, b, or c or anywhere convenient to any author
wishing to impose that sequence of pages on the site.
If another author (using another page) requires that
*sequence* x c */sequence* *sequence* b x */sequence*
then the compiler extends the solution to the order a, b, x, c. This satisfies all authors' sequencing requirements.
A similar process solves the nesting constraints. Finally, the compiler
modifies the structure so that a *contains* link points
to the earliest of the before-after pages any of which was explicitly contained.
As currently defined, sequences and nesting allow any ordered tree to be
specified: before/after specifies the in-order relation, and
contains/in specifies the parent/child relation. No page need
specify complete sequences or nestings; the compiler solves multidimensional
constraints to find a structure that satisfies the distributed orderings. As a
special case, the entire structure could be specified by a single file, perhaps
one on the user's server. That structure would specify remote files for the
compiler to collect. However -- and this is one of the most important advantages
of our approach - when authors wish to develop their pages, they do not need to
go back to any central structure specification. If an author wants to link their
page to another inside it, they could write *contains* y
anywhere in the page. If they wanted to put that page inside a page that
the rest of the site should refer to 'first,' it would be sufficient to write
*in* z. This would require the compiler to place the
file inside some page z. The compiler makes the 'tightest'
linkage that satisfies the constraints: in this case it would lead to z
being that author's 'top' page, and for the original page to be inside that.
An interesting consequence of the approach is that an author can compile their 'local' version (not necessarily geographically local) of a site independently of the other authors. They can do any quality control of their part of a larger site independently. Moreover, they can delegate parts of their authoring to other people, and so on without limit. (That is, the compiler can be run in many places on different components of a site, and can compile local components of sites.) Mark Addison has suggested that the compiler should compile its directives to HTML comments and, if it also parsed comments looking for directives, it could compile object pages, so they could be treated as source pages for other documents.
The compiler displays a 'dot and arrow' graph showing the site's structure. The compiler user can add new links (by direct manipulation) between pages before asking the compiler to actually compile the site. When this is done, the compiler generates constraints in exactly the same notation as authors use in their own pages: if this output from the compiler was itself compiled with the original pages, the interactively modified structure would be recreated.
Finding the site structure from the constraints is straightforward, though there are some subtleties - mostly in deciding what sort of structure one wants for a Web site in any case! For example, should cycles be permitted? In our case, we decided that cycles were inappropriate. Further, we wanted to be able to create a linear version of a site, rather like a conventional print document, and therefore required a structure that could be related to a linear document intuitively. Given these two requirements, the goal is to find an ordered tree that satisfies the constraints. A linear document is then simply a preorder walk of the tree.
Further assumptions must still be made. For example, does *sequence* a b */sequence* require a to precede b in the preorder, or, more specifically, for a and b to be children of the same parent page? We decided on the latter.
These decisions still leave several ambiguous cases, such as:
Whenever processing proceeds 'as if' some constraint had been processed, a copy of the constraint is saved to a file that can be reprocessed in the future, to ensure that the precisely same structure is preserved.
A system that supports distributed web authoring has to balance a trade-off between three criteria:
We believe that the prototype balances these issues well, but leaves enough scope for useful future research! In particular, the prototype makes very few commitments to page representations, and is therefore a versatile tool. In fact the scheme described here is distributed and structurally more flexible version of an earlier system (Thimbleby, 1997) which used a centralised database.
Kenneth Arrow's Impossibility Theorem (MacKay, 1980) showed that there is a natural set of criteria for social ranking that is inconsistent. This paradoxical result shows that there is no consensual choice algorithm for a home page that all authors would agree on (in the sense of the Theorem). Likewise, there is no consensual way of agreeing on other pages. It follows that any scheme, including the one proposed in this paper, is inadequate for general purposes, since no scheme can satisfy all reasonable requirements for web design. The Theorem allows for particular schemes for particular purposes (e.g., only one author, or all authors agree - or are required - to use a set structure), which is how most co-ordinated web sites are currently generated. Taking Arrow's Theorem more positively, it follows that any 'general' scheme such as the one proposed has an infinite number of extensions. We discuss just a few below.
Perhaps the most obvious development would be to move away from the conventional compiler model, and instead generate pages on demand. Although this would make the generated web sites more 'trendy' it would actually add nothing to the theoretical generality of the scheme. Arguably it would reduce quality control: at present, each version of the web site is generated by a deliberate and planned act of a single user - if sites were continually updated, it would be possible for authors to lose track of their versions.
As presently conceived, the compiler has to be run 'often enough.' This is not a satisfactory solution as the number of authors grows. There are many alternative arrangements, such as the compiler regularly visiting authors' sites, authors notifying the compiler (e.g., by email). It might seem ideal to completely automate compilation or to permit it to be run incrementally from anywhere. Yet large scale authoring is a collaborative activity, and it may be wiser for the compiler to provide more interactive support for communication between authors. For example, it would be easy to make the compiler provide direct support for user-author or author-author email, as well as compiler-author communication (e.g., for telling authors about problems with their own pages). The compiler might also track requests from one author to another (or from one author to the same author!) to undertake some writing, and (in many cases) it would know when such commitments were discharged. Fortunately these issues are orthogonal to the structural and design issues that have been solved by the present scheme.
The current compiler solves constraints sufficient to simulate any conventional print document: with ordered sections, and arbitrary nesting of sections within sections. Compared with current practice, this is passé and real web sites should be much more interesting! Though it may be useful for some applications to simulate paper documents, this is by no means the limit of a compiler approach. For example, Edward de Bono (e.g., 1991) has suggested that thinking can be usefully organised using 'six thinking hats.' Each of the six hats is a particular colour; white is the colour associated with information, black with making judgements, and so on. Our approach could handle this, merely by extending the two sorts of relations (before/after and contains/in) to six. In this case, it may or may not be important for the reader of sites to actually see the colours. However, it would be fun to colour object pages, and have their shades change as the reader browsed. The direction of colour changes on each page could give the user a good feel for the local site structure, and what sorts of pages could be anticipated in various directions. de Bono suggests that thinking hats would help authors more than readers, and Thimbleby (1994) discusses a system that explores the advantages for hypertext authors.
An author may refer to a page that does not yet exist. This is not so much an error as a natural consequence of authors undertaking the huge task of writing large web sites; inevitably they will lose track of some pages that were supposed to be finished, or even created, but weren't. At present, we compile such a 'page' using a null-page design template and warn the user of the compiler - not the author of the page. An alternative would be for the compiler to ignore null pages; furthermore, an actual page - one an author has started to write but hasn't released for public use - could declare itself to be 'under construction' and then it should be treated like a null page. This would mean that readers of a compiled web site never saw pages that were not ready for use. More precisely, null pages can occur in two places: as leaves of a site (in which case they can safely be ignored) or as central nodes that are required to 'carry' navbars. In the latter case, the null pages either should be elided with adjacent non-null pages (so that the navigational information is not lost) or they should be compiled with a suitable design style, just to create signposts for the site.
The compiler could easily produce public and internal versions of a site. For example, an author might want to wait until they could see a draft page in situ before releasing it for the public site. Once such a mechanism works - being able to include or exclude pages from the site -- the criterion could be broadened: 'under construction' is not the only sort of reason for hiding a page. One might want to create 'executive summaries,' for instance, that only show the top level pages of a site; or one might want to create sites with public information and with proprietary information; and so on.
As well as being (or not being) under construction (i.e., ignored or included), pages can have very many other properties that can be used usefully by a compiler. Additional properties include:
An author can refer to any pages using the standard href and other HTML references. Using a compiler, it is possible to extend the semantics of references considerably. An author may want to insert a reference to a file that contains certain text that is known to be on a particular server. A compiler can easily resolve such references.
Knowing the properties of pages, the compiler could modify links to pages in navbars or links written explicitly by authors or by other means so that they had consistent and appropriate style. If a page is flagged as 'new' then some (possibly all) links to it could have an associated new icon. If Edward de Bono's hat colours were used on pages, then the links to them could be coloured appropriately.
Many resources used in a large document require significant work from the author. A simple example is the provision of alternative (alt) text for images or a width and height for them. A compiler can easily provide a built-in database of such details, and ensure that they are used consistently (unless locally overridden, in which case it might provide a suitable diagnostic).
The compiler creates a graphical image of a site, which the user can edit and manipulate in many ways. They can view ranked embeddings, and see structure in a site that is very helpful in evaluating its design. Such views might also be useful for readers of a page, as an active map, so that they better understand where they are within a site and where they can go. We ought to extend the compiler so that it can generate image maps for use in navigation.
Variables may be defined in any files, and their values obtained by a simple inheritance mechanism (using the tree structure of the site). Thus it is easy to refer, say, to the icon (i.e., an author-defined variable name) of any page, and in particular, it is easy to refer to the icon of the next, previous and up and down pages - using a simple syntax that allows the values of variables to be obtained from other files.
The value of a variable defined in any file is not sufficient. It is also necessary to generate links to the appropriate files. The compiler provides a mechanism for retrieving the file name where a variable is defined, and using it as a HTML link.
| Code | Meaning |
| *get* var | Value of var. |
| *ref* var<x>text</x> | Make text a link to where varis defined. |
| *refget* var<x>text</x> | Abbreviation for *ref* var<x>*get* var</x>. |
There are a range of ad hoc features that ease writing web pages. For example, writing *symmetric* before any anchor converts it to a symmetric link: given a href/name link in either direction, the compiler generates href/name links in the other direction, hence making the link symmetric.
There are a wide range of built-in variables that provide useful information, such as the date. However, to avoid the compiler accreting a wide range of arbitrary features, Java objects can be loaded and run. The compiler passes the object parameters from the source file and inserts the stream output of the object into the compiled HTML. Java provides a clean interface so that authors can do almost arbitrary things to suit their own needs, to share libraries of features, and do so without the compiler getting more complex or harder to maintain.
We have described a very simple but powerful scheme for organising distributed web authoring. Individual authors can write pages or create design elements. The structure of the overall site can be specified in one place, or it can be distributed. Pages can specify where they wish to be within the overall structure, and the compiler solves constraints to find the most compact structure that satisfies the authors' requirements. Each page inherits a design template from the structure, and this ensures a consistent web site design, yet allows considerable flexibility. Design templates can place navigation menubars and other features so that users can browse the structure of a site conveniently.
The current scheme is a powerful approach on which to build more sophisticated authoring tools. We argued that the number of extensions was endless in principle, and we gave a few examples of extensions to explore the potential for development.
E. de Bono, I am right. You are wrong, Penguin Books, 1991.
A. MacKay, Arrow's Theorem: The paradox of social choice. Yale University Press, 1980.
D. Sano, Designing large scale web sites. John Wiley, 1996.
This project is funded by EPSRC under grant number GR/K79376. The author is grateful for input to the ideas expressed in this paper from George Colouris, Gil Marsden and A Min Tjoa.
Harold Thimbleby