Multi-Head Multi-Tail Mosaic:
Adding Parallel Automata Semantics to the Web

Scenario

Authors of computer-aided instructional material have, traditionally, had great control over the order of presentation of their material. The power of hypermedia, though, is that readers can follow train-of-thought explorations in linked information structures. As CAI applications migrate to the Web, authors find HTML restricts their ability to express orderings more complicated than a linear progression. Our methods allow authors to integrate some control of presentation order with this traditional browsing freedom. The generalizations of the link we have created allows a mixing of both capabilities.

As a concrete example, consider the following scenario: A pathology instructor is preparing a corpus of information to teach students how to read an autopsy report. For pedagogical reasons, the instructor has three goals: 1) Students should always be aware of the autopsy protocol (the summarizing cover sheet for the autopsy). 2) Students should refer to both the textual description and high-resolution photographs for most sections of the autopsy. 3) Due to the nature of the current case, students should not progress past the internal examination of the neck without having already seen the external evidence relating to the neck.

Two considerations guided our extensions of HTML: Ease of use for authors and logic of presentation for unmodified browsers. Using existing constructs as much as possible forwarded both goals. The tendency of browsers to ignore unrecognized tags permitted us to accomplish the second goal fairly easily.

Example

A multi-headed/multi-tailed link is enclosed between a <MHMT> and </MHMT> pair of tags. Between these tags text, anchors, and our incoming reference (<IREF>) tag are all treated specially by our modified browser. An example link from the autopsy training scenario follows:

<MHMT text="Continue to Neck" display_text="Show Neck">
<A href="/www4/head-neck.html">X-Rays</A>,
<A href="/www4/neck.html">Neck Photos</A> and
<A href="/www4/neck-desc.html">Neck Description</A>.
<IREF href="http://www.cs.unc.edu/~capps/mmm/head.html">
<IREF href="http://www.cs.unc.edu/~capps/mmm/head-desc.html">
</MHMT>

This example has three incoming and three outgoing links. Incoming links are defined by the <IREF> tag, but remember that the file containing this MHMT definition is itself the head of one of the incoming links... so only two <IREF> definitions appear. Refer to Figure 1 to see how MMM displays and follows this multi-link.

Figure 1: Following the "Continue to Neck" multi-link.

The author's intention is that this link only be active if the current page (head-neck.html), the head photo page (head.html), and the head description page (head-desc.html) are all being displayed by the browser. Note that there are only two <IREF> tags; the current page is always implicitly in incoming link to any multi-link. As can be seen in the diagram, the multi-link is displayed in the browser window with the contents of the TEXT field in the MHMT tag. When the mouse pointer is over the active multi-link, the DISPLAY_TEXT field's contents are shown in the browser's status line.

The author's second intention is that the head photo and head description pages should be advanced in parallel to the neck photo and neck description pages. In terms of the MHTML, the current page and any pages refered to in <IREF>s in the multi-link will be closed and any pages listed as anchor references in the multi-link will be opened in separate windows. Hence the three anchors in the MHMT construct above lead to the three pages in the bottom portion of the diagram above when the mouse is clicked on the multi-link. Note that the multi-link is no longer active (display color went from green to black) since the two pages in the <IREF>s are no longer displayed.

So, with the MHMT construct the author has control of what the user sees, where the user is told that he is going (as opposed to the bare URL displayed by most browsers), the pages the user must have already visited (synchronization), and the pages the user will see afterwards (concurrent browsing).

As seen in Figure 2, an unmodified browser displays the three outgoing links as regular anchors. This is because they appear in standard HTML anchor constructs within the MHMT region and the MHMT region id ignored by unmodified browsers. The <IREF> tag is also ignored. Users of unmodified browsers are able to use an MHTML document, though the author's concurrency and synchronization semantics are lost.

Figure 2: A multi-link in an unmodified browser.

MHTML's extended syntax

Recall our example: A pathology instructor with three goals: 1) Students should always be aware of the autopsy protocol (the summarizing cover sheet for the autopsy). 2) Students should refer to both the textual description and high-resolution photographs for most sections of the autopsy. 3) Due to the nature of the current case, students should not progress past the internal examination of the neck without having already seen the external evidence relating to the neck. A PFA presenting the entire autopsy report as it should be read for study appears in Figure 3.

Figure 3: Overview of the autopsy report.

There are two approaches to structuring the presentation in HTML: change page content or describe how to create the next desired browsing configuration in the document. The first presentation goal of keeping the autopsy protocol visible for the student's entire session with the autopsy can reasonably be handled in either way. Since the autopsy protocol is relatively short it could be prepended in its entirety to every page in the corpus (a task potentially simplified by server-side includes). Alternatively, the author could place a statement above the links to the internal and external examinations that they should be opened in another window, perhaps including instructions on how to do that with various browsers.

These approaches may well work in this case because the autopsy protocol is short (necessary for the first approach) and the desired browsing semantics are simple (necessary for the second approach). They would fail in the face of longer documents with arbitrarily complex browsing semantics. MHTML solves the first presentation goal with a minimum of hassle: each link to one of the examination pages is really a multi-tailed link specifying the autopsy protocol and the appropriate examination page as tail pages. The autopsy protocol does not participate in any other MHMT links so it remains up for the duration of the student's traversal of this material.

Either approach to HTML can be used with the second presentation goal that students see text and photos simultaneously for various sections. Modifying the appropriate sections to include the photographs in-line takes advantage of one of the Web's most compelling features. In this case, however, the images are as tall as the Web browser's presentation area; scrolling up to see the picture and down to the descriptive text distracts the student. The instructor could include directives to the students to bring the images up in another window and to advance both the image and description pages as they move from section to section.

This second presentation goal is addressed directly by MHTML: links from section to section are multi-headed (including the description and image pages from the current section) and multi-tailed (including the description and image pages from the next section). For example, look at the link from Major Organs and the associated Organ Photos page to the Head, Head Photos and Head/Neck X-Ray pages. (Note also that going from the Head and associated images to the Neck and associated images the Head/Neck X-Ray page remains visible like the autopsy protocol above.)

The third presentation goal, synchronizing the browsing of two browsing paths, is much harder to handle in HTML. It would be possible to modify the Neck section of the internal examination to include the text and photos of the External Evidence Photos and Evidence and Valuables sections, though if the student had seen them before this would be redundant. Alternately, a pointer to the Evidence and Valuables section could be included with an admonition to make sure it is seen before proceeding (it would then be necessary to handle a photograph and description as in presentation goal two).

In MHTML, browsing state is kept through the use of "empty" or "invisible" pages, which are marked but not presented to the user. Invisible pages are indicated in the PFA diagram by dotted outlines. Viewed Neck is one such page which is marked in parallel with the Belt Photos and Evidence and Valuables sections and not unmarked until it is used to pass beyond the Neck section of the internal exam. Hence if the student has seen the evidence information at some time during this session, it is possible to pass beyond the Neck section as soon as it is entered. If not, the student can follow the multi-link to the evidence description and photos, activating the link past the Neck section.

We simplified the original design and implementation process as much as possible to allow us to test the feasibility and usefulness of multi-links in Web browsing. We feel that we have proven the practicality of the MHTML construct and interface, and have seen numerous direct applications of its functionality, including the scenario discussed earlier in this paper.

While the original modifications to the Mosaic package were simple, they were made keeping extendibility and flexibility in mind; indeed, the groundwork for some logical enhancements to our original design is already included. First and foremost, with the increasingly frequent new Mosaic for X releases, we found it necessary to make our changes easily portable to new versions. As new releases become supported by NCSA, we will update our patch files accordingly. Now that the feasibility and usefulness of MHTML have been shown we expect to extend the HTML parser to parse MHTML directly, removing the current preprocessor.

Development on increasing support for Petri net (and other graph type) attributes is continuing as demanded by trial users. Multiple marking (plural tokens) and multiple marking modes (colored tokens) are two examples of this. In addition, we hope to allow the user to select a specific graph model, like And-Or, Petri net, or General, for interpreting MHTML. Related to this, and certain to make MMM much more attractive to authors, would be creating a graphical authoring environment for building MMM documents or sites.

Probably the single greatest hindrance in reaching the goals of the project was the requirement that MHTML be handled correctly by a unmodified web browser. We feel that one of our best directions for new development will be to remove that restriction.