Hypermedia are compound documents that allow users to traverse a document space in a flexible order by means of "directed jumps" between parts of the document space. Such jumps can be arbitrary, but often are tailored by a document author to provide a set of meaningful paths through the space. This allows progressive disclosure of information, the ability to add new, supporting information, and the ability to annotate. Hypermedia can encompass multimedia by allowing "documents" to be data types other than text with links.
The tools in this category support viewing hypermedia documents
and navigating hypermedia webs. Some of the tools discussed are
client-side browsers only, while others also include servers.
A closely related topic is HTML Authoring Tools.
The main issues are how the document space presents to users and how the system is organized internally.
[Marshall & Shipman, CACM, 8/95] draw a distinction between:
The differences between these metaphors is rather great, and has implications for both the user view and the duties of the client and server. In all three models, there are documents and relationships between them, but the similarities end there.
In the document-centered systems, links are part of the documents themselves. This manifests itself in the client because users are presented only with links they can see from a particular page. As a result, document centered systems do not do a good job of orienting the user within the document space by providing robust context; such context as is provided typically consists of the currently traversable links from the current document (of which there is only one at a time), the stack of pages visited, and a "hot list" of frequently visited pages. As a result, disorientation is a common problem. Because links are presented to appear as if directly embedded within the documents, they are usually stored this way as well. Representing links this way makes the addition of new links impossible without modifying the document, which is not always possible. Further, because the links are represented in only one place, local, user-specific links are not possible. A consequence of the limited view of links is that only a few, predefined link types exist, with the differences being limited to naming conventions for local or remote links rather than semantic differences such as "annotation", "subpart", "parent", etc. This also tends to work against providing a rich orientation to the user, since all links appear the same when displayed.
The intent of browser-centered systems is to eliminate the problems found in the document-centered systems, particularly disorientation and the inability to add new links. Browser-centered systems diminish the importance of the document, and replace it with a browser that has more contextual knowledge of the document space. The key idea is that links are not logically part of a document; rather, links connect documents without being part of them. This does not preclude links being displayed within document text. Because the links are not logically part of the documents, they are more accessible to the browser, which then uses the link information to present a partial map of the document space. Links are often stored outside the documents in separate files or objects. This lets the browser obtain link and document type information without having to load an entire document, thus facilitating the creation of a document space map local to the current document. The browser makes use of these semantics to display not only the documents, but the relationships between them. . Rather, links connect documents in a variety of often semantically meaningful ways (annotation, part-of, etc.).
Spatial systems eliminate the notion of explicit links between documents entirely. Instead, they model the information space as an n-dimensional space in which documents have positions based on their content and logical relationships to other documents. This relative position shows both document similarity (by proximity) and relationships (by positioning patterns; e.g., a tree , a stack, or a cloud). Documents are positioned in the space either manually to reflect intent, or by clustering based on document content using techniques similar to those used by search engines (see Searching and Indexing). Document positions are known to the space rather than the individual documents (although there may be a mode to represent the positionings of existing documents that do contain embedded links). This allows multiple spaces over the same document collections to be used to represent different points of view.
All hypermedia systems examined were architected as client/server systems. This division takes advantage of the fact that there are far more consumers than producers; that producers require a lot computational power, but little in the way of display capability whereas the reverse is true of consumers; and that there needs to be a very open way to attach new clients, servers, client types, and server types. Unlike many other client/server systems, browser clients and servers are not required to be well acquainted with each others' capabilities or even existence. This is achieved through the use of a protocol for negotiating presentation formats.
Hypermedia "systems" can be either tightly or loosely integrated. A tightly integrated system controls all or most aspects of authoring, displaying, transporting, storing, and validating documents in the document space and the document space itself. This gives the ability to enforce standard "look and feel", document quality, link integrity, etc. Tightly integrated hypermedia systems often have trouble scaling to large numbers of pages and large numbers of independent authors. In addition, the ability to add new media or display platform types may be limited because the new viewers these require must conform to the expectations of the existing authoring tools (and existing documents). For example, if authoring tools make demanding assumptions about how the resultant document will be displayed, display on a low resolution device may be impossible to reconcile.
Loosely integrated hypermedia systems relax these controls to one degree or another. In a loosely integrated system, a minimalist set of constraints exists. Typically, no assumptions are made about presentation format, storage, authoring tools, document validity, or even document space validity; all of these are expected to be provided by someone else. This makes it possible to add new variants of practically anything at the cost of "look and feel" standards and inconsistencies in the document space. Loose integration lends itself to situations where "reach" is more important than predictability; e.g., research collaboration vs. managing an inventory system. Loose integration is more heavily reliant on protocols than are tightly integrated systems.
Naturally, there a continuum of integration levels rather than a duality. Several tightly integrated systems have "escape" modes that allow them to function at a degraded level when viewing documents from outside their control (see Protocols).
In both loosely and tightly coupled systems, there is a need for negotiation between clients and servers about the types of data to be transmitted and the meaning of the data. Loosely coupled systems can make no assumptions that clients and servers speak the same hypermedia dialect or have full coverage; hence a protocol is needed to let clients and servers determine each other's capabilities prior to an exchange of data. Tightly coupled systems in general do not have this problem, but do have the problem that since their native document format is not universally used, it becomes very important to support "foreign" formats that are available on foreign servers. Actually, loosely coupled systems have a similar issue, since the flexible definition of what constitutes hypermedia makes it desirable to support wider and wider ranges of document types. Both of these goals are met through similar mechanisms based on protocols.
Protocols cover three basic areas. Specifics are given from the WWW, but other systems are similar. See Berners-Lee et al, CACM, Aug. 1994.
Tightly integrated hypermedia systems generally support access
to HTML servers as foreign sources. This is done by either using
HTML as the base for more complex document or navigational information
supported by the tightly integrated system, (in which case the
HTML is simply a degenerate case of the full format), or by supporting
HTML as a format in the same way WWW clients support access to
other formats. The tendency is for highly integrated systems to
support WWW and other major legacy protocols such as Gopher and
WAIS. There do not appear to be any attempts for these systems
to interoperate with each other.
Systems divide into two major categories: browsers for the WWW, and integrated hypermedia systems. The two categories are not completely independent, since integrated systems generally can produce HTML readable by WWW browsers, and can display HTML as a degenerate case of the system's complete functionality.
The dominant loosely coupled hypermedia system is the World Wide Web (WWW). The WWW is so loosely integrated that it is possible not to even consider it a hypermedia "system", but it is extremely well used, very popular, and provides a very nice model of how even a tightly coupled system could be modularized. WWW use is increasing dramatically (doubling every 4 months) and there is concern that it will eventually swamp Internet bandwidth capacity. For a nice glossary of WWW terms, see NCSA Glossary. [Berghel, CACM, 1/96] provides features matrix of a number of WWW browsers.
The WWW runs as a client/server system; any sufficiently powerful machine can be a server. The WWW defines a set of protocols for addressing (URLs), transporting (HTTP), and markups (HTML) that specify how the contents of the pages are to be interpreted by a viewer. The protocols hide location, server type, and document format from the user.
There are many WWW clients available. The most popular are Mosaic and NetScape. There are also many servers of different styles. Servers can dispense files containing HTML marked text, but can also be programs that retrieve information from a database or compute results and format them appropriately for transport. Virtually anything can be encapsulated in the WWW, even if not supported directly by HTML. Even real time audio and video are accessible via browsers, with the connections between server and client player being established via an HTML link and the HTTP protocol.
Rendering (displaying) a page is the responsibility of a viewer. A WWW client will use several viewers to display various media types. The page carries enough information encoded in the HTML that the client can determine which of its available viewers (if any) can display it. Adding viewers to a client is very easy, and clients generally support this via menus. This makes it easy to add new data types, since a client can be provided with a viewer for that new type and attach it. Not all viewer will display in-line, which creates a kind of second-classness to some viewers.
Different clients may have different viewers for the same media type. This allows viewers for low resolution devices to render a page in a reduced space or clarity. It also would allow filtering of pages to be done prior to display for various purposes. A consequence of this is that the author of a page cannot know for sure how it will be displayed, thus making it difficult to create sophisticated pages with an assurance that the sophistication will show.
Clients provide limited context information about the current page; essentially just the stack of pages traversed to get there. This is often cited as a disadvantage to current clients and of the WWW itself, although the problem seems to be more one of client capabilities than the WWW protocols.
WWW itself does not check validity of the HTML on a page; errors are discovered by the viewer. This actually works in favor of an open system because it means that new HTML markup types can be added without requiring the update of all viewers, they simply treat the new markup as an error to be ignored. A similar advantage accrues to private markups and viewers, although a proliferation of private styles would reduce the WWW's natural interoperability. NetScape (and probably other browsers we are less familiar with) is very good at ignoring bad HTML and displaying the rest of the page.
Similarly, WWW does not guarantee the integrity of the document space; i.e., there is no guarantee that a link actually leads anywhere or the referenced page is actually available. Again, this has advantages in an anarchic setting to compensate for the obvious disadvantage of quality of service, since the late binding of the check (during traversal) handles both non-existent pages and unavailable servers, which must in any event be handled.
Links can point to the results of queries, which are given a URL based on the URL of the base page and the query. An interesting question when caching occurs is whether two URLs based on queries are the same if the base page changes without the cache being refreshed. In Netscape, you have control over how often a cached page is verified (every hit, once per session, never). Hitting "reload" forces the page to be verified. Verification only consists of checking with the server to see if there is a later version of the page and getting it if there is. It is unclear what the "query" equivalent of "reload" checking is.
[Byte, 11/95 pg. 60] provides a critique of the WWW and points out a number of shortcomings. These are:
To these can be added the deficiencies that the various tightly integrated systems surveyed below are attempting to address.
gIBIS: [Conklin & Bergman, ACM Trans. On Office Information Systems, 10/88].
NoteCards: [Halasz, CACM, 7/88].
Hyper-G: U-Graz, [Flohr, Byte, 11/95] . HyperG is being developed at the Technical University of Graz (Austria); beta versions are downloadable. HyperG is a complete system of authoring tools, servers, and browsers. At the same time, HyperG can access non-HyperG servers, and be accessed by non-HyperG browsers. Any tool can be used for authoring, but if this is done the resultant documents will be browsable by HyperG in degraded mode. HyperG can and be accessed by WWW and Gopher; access to WAIS and FTP sites are planned. HyperG servers support session connections instead of the individual page transfer protocols. HyperG has received many favorable comments in the press.
SEPIA/SPI: [Thuring, et al, CACM, 8/95]. The goals of SEPIA/SPI (an authoring system and a browser) are to create and display well structured hyper-documents in an understandable way. The creators investigated cognition theory to determine the important aspects of how documents are comprehended by a reader and extrapolated this to hyper-documents. The clearly stated assumption is that SEPIA/SPI are for use with "authored" information rather than browsing an unstructured space like the WWW. The authors speculate that some of the ideas from SEPIA/SPI would possibly be useful in web browsers, but no work has been done along those lines; the system cannot even read WWW pages at present.
Eight design principals are expressed. They increase document coherency at local and global levels (i.e., how well connected are ideas that appear near each other and in a larger context), increase the ability to be oriented within a document space (where are you, how did you get here, where might you want to go), and decrease overhead of housekeeping (resizing, overlaying, switching screens).
Nodes and links are typed. A distinction is made between compound documents and related documents because this is important for cognition. Multiple panes provide different views of the same part of the document space giving detail and context. Visual queues of color, shape, size, etc., give consistent meaning to displayed information. The emphasis is on predictability, with the understanding that an author knew how a document should be read in a particular context. It appears that multiple application contexts are possible over the same document space, enabled by the typed links. Common vocabulary of node and link types is provided. Links are explicit, although they do not seem to be inside documents, but rather something "around" documents that holds them together; however, this may be a misreading of the article, which concentrated on the "interesting" parts of SPI; adding embedded links does not look like it should be hard if they are not already there.
SEPIA/SPI is being used as part of a tele-collaboration project for the remodeling of the German capital.
VIKI: VIKI is a prototype system under construction at Texas A&M. The focus of the work is a spatially oriented browsing of hypermedia documents. The claim is that this style of display is more effective when relationships are not understood, are fuzzy, or may change. Many examples are given in the article. Nodes, collections, and composites can be typed; attributes can be added to show visually the importance of given nodes. Menus are used to create nodes of given types or to create composites of already established types. There is apparently some capability to infer composites based on spatial orientation, so VIKI can make guesses about whether two spatial groupings represent the same information.
VIKI maintains spatial information outside of documents so that new information can be added to existing documents. This allows VIKI to be used to manipulate WWW documents; it is not clear what degradation of VIKI capabilities (if any) result from this. It is also not clear ho VIKI handles HTML anchors in WWW documents. Little is said about storage management in VIKI. Presumably link integrity is irrelevant because links are not explicit. However, nodes are referenced at least in the spatial map so there must be a way to check these at runtime.
Questions that arise are how effective spatial display is when large numbers of nodes, types, and composites are to be manipulated. How do embedded anchors fit into a world where fixed links are not used? If orientations are used to convey meaning, how does VIKI reconcile multiple spatial orientations that mean almost the same thing, the use of the same orientation in different places to mean different things. This flexibility looks like it opens up the multiple schema problem in yet another domain. No mention is made for how VIKI addresses these issues.
Pad: Pad is a browser being developed at the University of New Mexico that uses zooming as its primary metaphor. Any object in an information space can be zoomed in on, with more detail being displayed. Advantages claimed for the zooming metaphor are (1) that a single metaphor can be used for all types of document organizations, and (2) that knowledge of the type of the objects in the display region can be used to tailor how they display at a particular resolution. A single metaphor makes it possible to always think that "to see more detail, you look more closely". This seems useful, but not surprising. Use of knowledge of object type allows "lazy retrieval" of details when the details would not render well at the given resolution. For example, there is no need to fetch the contents of a file if the screen is displaying the entire directory. However, once the details have been retrieved, they can be displayed even after zooming back out, thus providing a visual cue as to where you have been.
Three examples of the use of zooming are given in their description:
outline viewing, file/directory viewing, and HTML document viewing.
The examples were more convincing for clearly hierarchically structured
data; i.e., outlines and files. The HTML example, because WWW
documents are not inherently hierarchical, seemed to suffer from
disorientation because newly visited nodes were not zoomed in
on, whereas previously visited nodes appeared zoomed in. Thus,
where you are is less important than where you were, which is
contrary to most attempts to reduce disorientation. This may be
a function of the immaturity of the HTML-browsing part of Pad,
personal style preferences, or just that WWW documents may not
lend themselves to hierarchical browsing. In general, the whole
area of determining the "best" display and orientation
style in hypermedia is evolving, and personal preferences may
dictate the use of several styles. Pad's attempt to use zooming
is interesting.
This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.
© Copyright 1996 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.
This page was written by David Wells. Send questions and comments about it to wells@objs.com.
Last updated: 04/22/96 7:42 PM
Back to Internet Tool Survey -- Back to OBJS