[Mirrored from: http://www.csu.edu.au/special/conference/apwww95/papers95/avercous/avercous.html]
J Jean Paoli
Vincent Quint
Irène Vatton
The success of the WWW came with browsers such as NCSA Mosaic that provide a user-friendly graphic interface for accessing information on the Internet. For displaying documents, all browsers parse the HTML files they receive from servers and interpret the HTML tags they contain. Accessing documents is done through link activation or by typing URL's. These features are at the core of any browser.
Editing HTML documents was initially done using standard text editing and adding tags by hand. Today there are many editors for producing HTML documents but they are still requiring in-depth knowledge of HTML. Most users check the documents they write by loading them into their favorite browser which may be connected to the editor or not. The reverse approach also exists where browsers like Mosaic or MacWeb let you edit the HTML source and save it into a temporary file. Indeed very few authoring tools for the Web are WYSIWYG, i.e. allow for editing the formatted document under the same presentation as, let say, Mosaic or Netscape.
Authoring a document for the Web also means creating a great number of links towards other documents. It is therefore very important for the authoring tool to be wired to the net and to let the author navigate until he/she finds the places of interest. The author can thus control the links being edited.
Symposia [2] is an SGML-based WYSIWYG authoring system that has been the first editor wired to the Web. As Symposia obviously offers the basic functions for navigating on the Web, the question arises whether it can be actually used as a browser. Great browsers are usually evaluated according to a set of criteria [PC95] : The displaying quality and efficiency, the navigation support, the configurability and the extensibility. The paper studies the features that are expected from advanced browsers by comparing some of the more used ones (like Mosaic, Netscape, Macweb) and discusses some aspects of the current navigation support. We show that Symposia offers most of these features and proposes some more advanced features that are (could be?) easily supported due to its SGML-based implementation and its extensibility through its API.
Symposia has been developed by Inria and Grif.S.A. as part of the European effort for the creation of more powerful tools for the Web. It is the first application of the European project WEDI (reference W1001) developed with the support of the European Commission, DG XIII. Symposia is currently in beta test on Sun, HP or IBM (RS6000) workstations and will be more widely available free of charge from Inria ( http://symposia.inria.fr ).
Symposia is based upon Grif, a WYSIWYG Structured editor which allows files based on any DTD to be loaded, edited and saved in native SGML format.
HTML has been designed as a markup language that represents the structure of documents, although it is often used by author as presentation-oriented. It was therefore quite natural and easy to fine-tuned an SGML authoring tool to HTML, which is just a specific DtD, still requiring some extensions to better fit the Web requirements.
The editor offers to the user context-sensitive menus that guide the edition and ensure correct HTML document structure and syntax. Based upon the logical structure of the document, it is possible to generically define the graphical aspect of documents. Therefore, unlike most of current HTML editors, Grif as well Symposia does not tag the text, but offers a tag-free WYSIWYG interface and allows authors to see documents exactly as they will be browsed.
Symposia is not restricted to textual document. It can also handle images (restricted to Gif format in the freeware version), or complex objects like forms, HTML3.0 tables and mathematics. For such complex objects the interaction with the WYSIWYG presentation is much more user friendly and nearly necessary for guarantee the HTML compliance.
However very few documents on the Web strictly conform the HTML DTD as many users produce HTML documents with simple text editors which ignore the DTD. Most popular browsers are very liberal and make their best efforts for displaying non conforming documents, but the interpretation may vary from one browser to another. In Symposia such flexibility is provided by using a specific SGML parser for handling each of the different HTML versions and accept HTML documents which are not strictly valid. When producing the internal Symposia structure that corresponds to the HTML document, it generates missing elements or attributes. Symposia is able to manipulate such incorrect structures but will allow for inserting new elements only at a position that is allowed by the DTD and therefore enhances the HTML compliance of existing incorrect documents.
From the user's point of view, the WWW is made up of a set of files, each of which contains many links to other files stored either locally or on some remote site. It is the coming together of these two elements (files and links) which is at the root of what a Web document consists of. An authoring tool for the Web must then provide an easy way of creating links within or between documents, for local files as well as for remote ones. Symposia provide direct manipulation commands for creating and editing links and anchors, without editing any tag. The main commands are:
These commands can apply not only to local documents but to remote documents as well. It means that any document on the web can be loaded for being edited or linked either by using the command OPEN URL or by following a link. Then Symposia is actually wired to the Web and you can access any document on the Web and editing it.
We have just seen that Symposia can load and edit any document on the Web. Symposia is the first authoring tool for the World Wide Web that makes it possible to save HTML documents directly on remote WWW servers which have been specially configured to accept the Web's HTTP PUT feature . Once the person responsible for the remote server has provided you with a user name and password, you can save and modify documents directly on the remote server, just as easily as on your local file system.
We have used the PUT element of the http protocol that allows documents to be saved in a location specified by a URL. PUT can be enabled without recompiling the server by adding some configuration files to enable, among other things, the designation of directories on a remote server where files could be stored.
Most servers are not set today to accept the PUT element of the http protocol. Security and management factors must be considered carefully before using it. We can expect that these security features will be enhanced in the future but we can already begin using it today, at least within the internal networks of corporations. Experimentation for cooperative editing on the Web can be carried out using such remote writable servers. Currently Symposia offers a basic lock/unlock mechanism for preventing several authors to concurrently edit the document. A more efficient and interesting mechanism would enable the locking of a specific fragment of an HTML document.
We have seen before that Symbosia provide the basic features for browsing on the Web, eg. loading any document and following links to others local or remote documents. The question arises then (and we are often asked for) whether Symposia can actually be used as a browser and compete with the more advanced existing ones. The evaluation will be done according to three types of criteria: the navigation features, the configurability and the extensibility.
Recent studies [Cat95]] of user browsing strategies under NCSA Mosaic have shown that the more frequently used commands are the following (the number between parenthesis refer to the number of recorded events ):
_____________________________________________________________________________ Selection of Hyperlink: (16176) Back: (12632) Spawn hotlist: (2336) ;including goto via Hotlist: (636) Open Url: (1753) Forward: (537) Close window: (481) Open local File: (487) Spawn window history: (237) ;including goto via document history : (39) Add current file to Hotlist:(207) Home Document: (179) Clone window: (25)_____________________________________________________________________________
Whilst it would be interesting to get the same information regarding Netscape, those results give at least an image of user interactions with one of the more currently used browsers.
Hyperlinks are by far the preferred method for surfing the net, followed in good place by loading local or remote documents. As said before these two features are at the core of any browser and part of Symposia as authoring tool wired to the Web. It must be noticed here that in Symposia user double clicks for following links while simple click selects the current position for editing. An alternative would be to switch between an authoring mode and a browsing mode.
Good display of documents in various formats is of course important. The SGML-based approach of Symposia support the display of documents in various HTML versions and can be easily adapt to new versions (including tables, mathematics, stylesheets) or standard presentations. Regarding other multimedia format (video, various image formats, sound), Symposia is currently restricted to displaying imbedded images in Gif format. Other formats for internal or external format will be added soon using the extension mechanism (see 3.5 ).
What also makes a good browser is the ability of marking places of interest and the ability to easily return to these places or to previous locations. The frequent access to Hotlist and Historic not followed by a "goto" suggests that they are not very well designed for the user to find out what he was looking for.
The approach of Symposia is to regard Hotlists just as other HTML documents and then to benefit of fully editing capabilities(see Fig.1. ). A specific menu allows for loading the Hotlist and add the current document to the Hotlist. No extra development was required to implement Symposia Hotlists with all the required good features, but providing the appropriate interface.
Fig.1. Symposia Hotlist: a structured document.
Examination of many Home Pages [Fur95] has shown that they are often used for collecting various pointers to places of personal or corporate interests. An explanation could be that users estimate current hotlists too poor in presentation, hard to edit and non practical through long menus. It seems a good argument in favour of Hotlists implemented as full (structurable) documents.
However this approach has the drawback of not enforcing a specific structure for hotlists and their reusability by other browsers . An alternative will be to specify an (SGML) rich structure for Hotlists that will be used by browsers for supporting more advanced features as described in [4.3] or more simple interfaces (removing all the tags that are not likely to occur in Hotlists). Hotlists would still be saved in HTML but would be coerced into this structure when parsed using the Symposia HTML parser. This approach has already be used for providing Symposia with a more user-friendly interface by grouping several tags into the same higher level structure [Qui95 ].
An historic save the list of references to the pages that have been previously visited. The user can visit again a place just by clicking on the desired anchor. The historic is generally associated with back-forward commands for returning to the previous/next document into the historic.
Unfortunately most browsers (including Symposia) have an historic management which consists in popping the top of the stack back to the current selected position as soon as a new document is pushed into the historic. It has the advantage of limiting the depth of the historic as well as defining a very simple and obvious semantic of back command (that is always returning to the element before the current one in the historic). In [Bro95] it is proposed instead that all elements are kept into the historic (without duplication) until the user explicitly discards them. When a new link is followed from a page already in the historic the new page is inserted just after. More sophisticated implementation for back /forward commands are therefore necessary.
Implementing and displaying historic as a more structured document will allow for editing, saving historic and implementing various back/forwards strategies (in first depth or width, for example . In Symposia, Historic is actually implemented as any HTML document but displayed as a menu for preventing any edition that could ruin the back/forward strategy. As for Hotlists a specific structure could be defined according to the editing and navigational capabilities which one wants to offer.
In the current version Symposia does not reverse access to an internal link through the back command. In Netscape the back command apply for local and external links since internal position into pages are recorded into the Historic stack. It has the drawback to increase unnecessary the size of the historic with as many instances of a page as accessed internal positions. A different strategy is proposed in section 4.1
Grif and Symposia are based on the separation between the logical structure of a document and its presentation.
As the logical structure of a Grif document always conforms the model of a DTD, it is possible to generically define the graphical aspect of documents: presentation rules are associated with element types and attributes and the editor applies them to the elements constituting the logical structure, thus producing the graphical aspect of the document. Presentation rules are expressed in a declarative language, called P. They specify such parameters as font, colour, spacing, line length, indentation, justification, etc. Presentation rules are gathered in presentation models . A presentation model contains all rules necessary to specify the graphical aspect of all types of elements and attributes defined in a DTD. Several presentation models may be associated with a DTD; the graphical aspect of a type of document can then be changed globally, just by changing the current presentation model. One can so define a model for screening the document , and a model for printing, with a different font or adding in the footpage the current URL and page numbering.
Currently the WYSIWIG aspect is limited to displaying tagged elements in accordance to what they would look like using another browser. When stylesheets will be available on the Web, the presentation will no longer have to be hard-coded into the browsers but attached to the document itself. The architecture of Symposia is ready to fit this approach.
Presentation models also define different views , which present in different windows the same logical structure with different graphical aspects. For instance, Symposia offers a view of the source code (showing the HTML tags), a view of all the anchors with their associated URls, and a view with page delimiter and numbering.
Views in Symposia are ``synchronised'', i.e. they display the same part of the document at the same time. When the user clicks on an element in any view, the same element is highlighted in all views where it is supposed to be displayed. In particular it is very helpful when opening the HTML source view for controlling it. In addition any view can be edited and all changes made in one view are immediately reflected in the other views.
With some browsers like Mosaic and Netscape you can open several windows and browse independently within each of them, with independant historic and back/forward activation. Each new opened page replaces the one previously displayed in this window. In Symposia, this is the default option, but you can chose to let all pages opened, or to "pin" some specific pages of interest that will be kept opened until you un-pinned them and close them. From a pinned page it is possible to open new pages that are all displayed in the same window, unless they are themselves pinned. However each pinned has its own historic stack that it is displayed in a common historic window; switch between various historics is done contextually according to the selected document.
Another approach is proposed in DeckScape [Bro95] . DekScape organises the accessed documents into "decks" that can be saved. A deck is contening a stack of opened documents of which some are put "away' (the equivalent of "pin" documents in Symposia). Like in Symposia new documents can be opened from "away" documents are added to the document stack, but there is only one global historic by Deck. Decks also encompass the notion of cession by locally saving the documents that has been accessed from a same Deck.
The main difference between Decks and hotlists is that a deck is a set of already accessed documents while a hotlist is a list of reference to those documents. Decks require access to locally saved documents. Whilst it is not clear yet if such decks should be saved or not, the idea of temporary Deck during a cession is interesting by providing the user with is a better control on an higher level caching.
The design of user interfaces to access or modify data on the WWW raises the need for WWW clients to support new data type handling, configurability, programmability and open-endness.
Extensibility is said to be dynamic if extensibility code can be loaded, installed and executed directly without re-building the software. It is said to be static if recompilation or rebinding of the software is needed to access the extended functions.
An interesting aspect of Symposia is its GATE function. With GATE, an API allows any program to access the editing functions that are proposed to the human user. Thus an application can drive the editor. GATE also allows developers to extend the editor functionality: an application can specify editing events in which it is interested and the editor gives it control when these events occur. It can then execute some specific treatments that can in turn call editing functions through the API. These two mechanisms are used for developing applications based on the concept of active documents [Qui94] .
In the following we are showing how Gate has been used for developping Symposia and its browsing extensions, as an example of the extensibility mechanisms in Symposia.
Symposia implements an object-oriented approach for tailoring the behavior of HTML/SGML elements: elements receive event messages reflecting the user interaction and in response they execute an appropriate action. Actions are written in C code.
Extending the User Interface is done through a declarative interface written in the so-called I-language that allows the binding of messages to elements, to specify which actions should be called, and to define new messages and menu items.
The following example shows how to define in Symposia a new menu for Anchor Edition and to create new messages associated with each menu item:
APPLICATION EDITOR;
DEFAULT
BEGIN
{ redefined actions for standard messages}
StdFollowLink: GW3_StdFollowLinkAction;
...
{ nonstandard messages sent by menu items}
CreateLinkMsg : CreateLinkAction;
CopyLinkMsg : CopyLinkAction;
EditAnchorMsg : EditAnchorAction;
RecordLinkMsg : RecordLinkAction;
PasteLinkMsg : PasteLinkAction;
DeleteLinkMsg : DeleteLinkAction;
MENUS
...
Anchor:
BEGIN
CreateLink: CreateLinkMsg
EditAnchor: EditAnchorMsg;
RecordLink: RecordLinkMsg
CopyLink: CopyLinkMsg;
PasteLink: PasteLinkMsg;
DeleteLink: DeleteLinkMsg;
END;
END
New menus (Navigate and Anchor) are defined after the keyword MENU; each menu item is associated with a new message. For instance the menu item "CreateLink" is associated with the message CreateLinkMsg that will be sent whent this item is selected. Actions are attached to these news messages in the DEFAULT part. Thus the action CreatelinkAction is attached to the messageCreateLinkMsg, and the corresponding code C will be executed when this message is sent. In fact the extensibility of the user interface goes far beyond the adding of new menus since actions can be attached to elements within the document itself, according to what is called the Document paradigm interface [Pao94] , [Ver91] .
While Symposia User Interface can be easily extended or modified by defining new I files (as Interface files), it is what we have called above a "static extension". I-files and actions, currently defined in C, must be compiled. To provide "dynamic extension" to the end user, they should be interpreted. However some configurability of the user interface is possible through command paramaters or the load of a startup_file. For instance, the user can switch between French and English for getting the Menu items or Editor messages in the wished language The screening allows for user- fine tuned level of zooming, in place of the only small, medium and large fonts offer by other browsers. This kind of configurability is available through a preference menu.
This method is very simple but has certain shortcomings:
Symposia has be designed for facilitate the creation and maintenance of data published on the Web. For that purpose its API implements a short list of functions on the top of the CERN network library for calling for network services (loading and saving Urls) and returning information required by the server (a password, for example).
The Symposia API provides a programming interface to the HTML/SGML structure and content: it supports element and attribute creation and manipulation, content modification, structural searches, and incorporation of fragments into the document. API functions are can thus be used to parse and integrate HTML/SGML fragments into the current document.
In this way, CGI scripts could be used together with Symposia to fetch fragments of documents rather then entire documents and integrate them into the current document. Reversibly any type of elements in the document could be defined as a containers to be interfaced with Server queries instead of the only forms fields.
The method used by Symposia offers multiple advantages but requires a certain amount of programming in C and is therefore less simple to implement.
Symposia extensibility through Gate API can also be compared to the Java approach.Java [Java 95] is an object-oriented programming language used for the creation of distributed, executable applications. Java was defined by SUN Microsystems which has also implemented HotJava, a WWW browser that can execute applets. An applet is a Java program that can be included in an HTML page, much like an image can be included.
However,
The greatest advantage of Java is undoubtedly the ease with which external applications are installed and accessed over the network.
Most documents published on the Web are cut into several small HTML documents, related to each other by links. This form is convenient for local browsing, but not for getting an overall of the document when authoring or browsing, nor for printing. Specific elements (LINK with attributes REL and REV) are defined in HTML 2.0 for describing the structure of these split documents. Currently such links are not taken in account by browsers since very few users are ready to pay the effort for authoring them by hand.
When these links will be created automatically by editors such as Symposia, it will be mandatory for browsers to exploit them. For example providing a global table of content for the set of pages of a document will be obvious and very useful. Currently some advanced tools or browser automatically generate such maps, by following links to a certain depth or restricted to a list of servers. But it is difficult to make any difference between links to pages of the document and links to external references. It will be much easier to take advantage of the specific link attributes to define which pages the document is made of. A global graphical and editable view of such links between pages, comparable to Miniwebs in NaviPress , could be implemented in Symposia , based on the structured editor approach.
There is also a need for reverse links, for example between a footnote and its reference or between a biblographic entry and all the references to it. In Nescape internal references can be followed back using the back command, i.e only when you have previously followed the link forward. it can be notice that Symposia offers a better highlighting of the link targets (displayed in green). Symposia could easily provide the list of all the internal links towards a given target and memorize into the historic those that have been activated. It could be extended to external links for all document already in memory, but it seems more relevant in authoring phase that in browsing one.
Some browsers allow a user to annotate Web documents. Mosaic, for instance, proposes that function, but with strong limitations: annotations are private and their contents are restricted to a simple character string.
When rich editing functions are available, it is possible to offer a more advanced annotation mechanism. Like hotlists, annotations may be structured according to a well defined model, for allowing specific application to work on them. As an example, if a specific type of annotation is defined in order to allow a reader to propose rephrasing of some part of a document, a revision tool could offer a command that updates the annotated part by the content of the annotation. Thus, annotations could support cooperative authoring of documents on remote servers. Symposia is also able to manage hypertext links between an annotation and the annotated part, in both direction. But it may be also useful, when writing an annotation, to reference other documents. As these references are represented as ordinary Web links, they can be used by other users, even if they use another browser.The annotations must then be accessed on their own and not only though the annotated document.
Finally, annotations considered in that way are not different from other Web documents. As the browser includes the full authoring functions, it allow users to write documents related to documents they are browsing. In fact, in many case there is not a clear difference between an author and an active reader.
As hotlist become rapidly important there is a strong need for editing and restructuring them. Until now it must be done by hand, even with Symposia. It would be useful to provide user support for automatic classification or reordering.
A flexible sort function has recently been introduced into Grif (not yet in Symposia, though). It allows an user to specify how some part of the document (freely selected) should be reordered. It is specially convenient for structure like itemizations, lists, bibliographies, indexes, glossaries, etc. It is based on the document structure: one or several elements of the items to be sorted can be chosen as sorting criteria and different ordering schemas can be selected for these criteria: numerical, alphabetical, chronological, etc. It could apply valuably to hotlists, especially if hotlists are rigorously structured. If such fields like date of first access, keyword, title, author, site, etc. are part of the hotlist structure, it is possible to sort a hotlist in a number of ways and greatly enhance the usability of hotlists.
The paper has show that beyond its initial design as an authoring tool for the Web, Symposia provides most of the navigational capabilities (link activation, flexible management of historic and structured hotlists, multi-views, etc.) without or with very few extra work through the extensibility provided by its API and the structure document approach. In many cases the editor even offers an improved function and has the potential for more advanced features like browsing of large documents and complex annotations management. Navigational structures as well as annotations can just be considered as usual documents and be fully edited, linked and saved.
The extensibility and flexibility provided through its Symposia API has the advantage of addressing the level of document fragments and enforces the paradigm of documents as interface. However Symposia's extensibility is still too static to support all the desired configurability or the dynamic integration of external applications.The issue of performance when surfing the Web has not be debated here. While the performance of Symposia for downloading distant Urls is already quite acceptable, there is an obvious need for a multi-threaded architecture for downloading of multiple documents in parallel or uncompressing image in background.