Hypermedia consists, roughly speaking, of a network of links
which connect nodes. A contained network constitutes a hyperdocument.
Nodes and links may also be visualised in a database diagram,
either as an entire hyperdocument or as parts of a hyperdocument.
This section of the lesson will examine the hyperdocument and the database diagram.
This section examines what we have chosen to call the composite
information units of hypermedia, which comprise hyperdocuments
and database diagrams. These are hypermedia units which are constructed
of the basic hypermedia units, links and nodes. A composite information
unit is a conceptual term, and a composite information unit does
not have to constructed by an existing (basic) information unit.
A database diagram (at times simply referred to as a diagram)
may be constructed manually by its author. Furthermore, a diagram
does not need to be represented as a separate unit at all, but
it may be dynamically generated by the system according to the
user's whereabouts in the diagram.
A hyperdocument is a collection of nodes and links. It may often
deal with a particular topic, and may be compared to an article
in an encyclopaedia or a book examining a limited field. A hyperdocument
will often have a particular structure, which is normally hierarchical,
but other structures may also occur.
A database diagram is a graphic overview displaying the structure
of all or parts of a hyperdocument. The nodes are usually displayed
as boxes or by link icons in the diagram, and the links are usually
indicated by lines between the nodes. A hyperdocument may also
contain a database diagram. A reader may generally move in the
hyperdocument by means of this database diagram. In some systems
the author may perform changes directly in the diagram. For example,
some systems permit nodes to be deleted or created directly from
the diagram.
Hypermedia uses the document metaphor to describe a collection
of nodes, links and diagrams which typically cover a particular,
delimited topic. A hyperdocument may be part of a larger hypermedia
base, or the document may in itself be a hypermedia base. However,
deviating from the definition above, some systems use the term
document about nodes, for example Intermedia (Yankelovich, Haan,
Meyrowitz, Drucker 88). In Xanadu (Nelson 90) the term "document"
is applied to any separate unit, for example an available link
to a topic, a node, or a collection of several objects. The latter
may also be a document according to the definition above.
Beyond the various hypermedia units (links, nodes and diagrams)
stored in the hyperdocument, so-called context information is
often also stored. This information describes various possible
states a hypermedia system may be in. A state may exist based
on different conditions. One condition may be which information
must be visible (filtering) to the user in the selected document.
Other conditions may be setting which node or nodes should be
open on start-up, and which paths or routes should be accessible
beyond the existing links. The system might also recall what the
user did when he or she last used the system.
Frank Halasz mentions so-called composites (Halasz 88,
p. 843-845). These are collections of nodes and links within a
document which may be managed as a separate entity. This permits
operations on the composite as a unit. This is the opposite of
a regular document, where operations must be carried out on each
of its constituent units. A composite may thus be considered a
sub-document. However, it is difficult to establish any large
conceptual difference between a document and a composite. We will
thus consider documents and composites as equals.
As stated in the introduction to this section, "composite
hypermedia unit" is a conceptual term. This means that the
conceptual unit hyperdocument may be represented in the information
model in various ways in a hypersystem.
One option is to let the document constitute a separate entity,
where nodes and links are represented. Node and link representation
may be done in two ways: directly or indirectly. In the direct
method the document contains a set of the nodes and links which
are part of the document. The links and nodes will thus be hyperdocument
components. This applies to NoteCards (Halasz, Moran, Trigg 87).
The figure below shows the principle for the direct method of
document representation.
In the indirect method the document contains a description of
characteristics, in the form of attribute values of links and
nodes which are included in the document. A special variation
of this is used in Intermedia, where the document entity contains
information about the information objects which are to be used
as nodes and the placement of links in the nodes. When the document
is opened the hypersystem constructs nodes based on the information
objects and the link information present in the document. This
enables using the same information objects as a starting point
for a number of nodes in different documents. This makes it possible
to present the same information in a number of variations. See
section 2.2.4 for more on node representation in the information
model.
Another option is to have no explicit representation of the document
at all. By opening an available node and following links from
this, it is possible to move around in a set of nodes. Conceptually
such a set of nodes must be considered a document. The requirement
is that the user has direct access to a node, which will then
function as an access node to the hyperdocument. If the system
has one-way links, the document will appear as a contained unit
for the user. When two-way links are used, the user may move freely
anywhere in the document, thus perhaps no longer sensing that
it is a separate document. KMS (Akscyn, McCracken, Yoder 88) utilises
this type of organising the hyperbase into documents. Figure 3.2
shows the principle of this method.
The third option is to allow nodes, links and documents to be
separate entities in the same hyperbase. This is the most flexible
way of representing documents. In an ideal system a document may
consist of an open quantity of links and nodes. Different documents
may wholly or partly consist of the same links and nodes, i.e.
a mathematical union. A node may therefore be linked to another
node or to another document. Links, nodes and documents may all
be handled as separate entities on which operations may be performed.
This representation is used by Xanadu, which is probably the closest
relative of Halasz' composites.
The structure of a hyperdocument is the overarching organisation
of the document nodes. By overarching organisation we mean the
primary order in which information is presented as chosen by the
author. The structure is maintained by organisation links connecting
the nodes.
An important issue much discussed over the years has been which
structures should be permissible in hypermedia, and/or whether
hypermedia systems should offer a fixed structure at all. Theodor
Holm Nelson and Douglas Engelbart disagreed on this, even though
both visualised the great possibilities hypermedia would be able
to offer as a tool "to extend the human intellect" (Engelbart)
and as a "thinkertoy" (Nelson). Engelbart believes that
hypermedia should use tree structures, while Nelson feels that
the user's own mental model of the information should be implemented
in the hyperdocument.
DeRose (DeRose 89, p. 249) points out that traditional documents
usually have a number of structures. They have two main structures,
the first being the purely linguistic structure of regular language,
with chapters, sections etc. The second structure is the physical
structure of pagination, lines etc. DeRose believes that hypermedia
should preferably be able to represent several structures in a
hypermedia document. Jeff Conclin shares this belief. He draws
special attention to the fact that it must be possible to present
the information in a number of parallel tree structures (Conclin
87, p. 35).
Most hypersystems require or at least encourage authors to structure
hyperdocuments hierarchically. As there is also a need for other
structures, in the following section we will examine different
ways of structuring hyperdocuments.
One aspect of hyperdocument structuring is that it is rather the
specialised applications with hyper-functionality which have used
structures other than the tree structure. One reason for this
may be that these specialised applications may have been designed
by specialists, while typical hypersystems are intended as authoring
tools for normal users. Therefore document structuring has never
been all that much of an issue when discussing hypermedia systems.
Therefore, one of the sources for the following sections is Apple's
Design Guidelines (Apple 89), which are intended for designers
using HyperCard.
Theodor Holm Nelson argues that the user's own concept of the
information must be modelled. Nelson states that a hypermedia
system must be able to represent any structure the user wants.
He writes the following on the requirements for a hypermedia storage
system (Nelson 90, p2/26):
" ... It is therefore the representation
of this structure -- of whatever structure the user may be concerned
with -- that should concern us. But the things you work on can
be staggeringly complex. So we must create a general system of
representation that will automatically hold and present any possible
structures you want to work on."
Such an optional document structuring may manifest itself in various
ways. It may either result in a more or less haphazard network
structure, or the author might construct some kind of systematic
structure.
A random network is not linked according to any system. The user
constructs new links as his ideas develop, without having to adapt
to any pre-defined structure. As this type of network does not
possess a fixed structure, the reader may become confused. Understanding
the architecture might be hard, thus making it difficult to move
around in the document (Apple 89).
Even if a hypersystem permits an author the use of a free structure,
s/he may nevertheless choose to employ a more systematic structure.
Nelson believes that templates should be used wherever possible.
The author then defines a template, e.g. a node template, which
will contain a number of links to maintain the structure of the
document.
With some exceptions, the tree structure has been the most common
structure in existing systems. A drawback of organising information
in this way is that it compels the author to structure his topic
into a hierarchy. For readers, however, two special advantages
are connected to tree structures. Firstly, navigating in a tree
structure is easier. A reader may move back to the parent node,
or on to one of the offspring nodes (in addition to any reference
links). Moreover, it is easy for a user to visualise a tree structure,
thus making it easier to orient him/herself in the document.
The figure below shows three possible tree structures (taken from
Apple (Apple 89, p. 26-28). The topmost structure is often used
in hypermedia systems, for example KMS. Each node may have a variable
number of offspring nodes, and a parent node. The next structure
also allows moving between sibling nodes. The final structure
is more special, as no branch of the tree is permitted to branch
further. This structure may be compared to that of a book, where
a user may jump to any chapter from the table of contents.
Linear structures consist of a series of nodes. A reader may thus
follow links in two directions only, forward to the next node
or back to the previous node. Conceptually, this structure has
characteristics in common with guided tours, see section 3.1 in
lesson 7. This structuring method lends itself well where there
is no requirement that a user can move around in the document.
The drawback of this method is that the user cannot move in the
document at will. Typical applications are demonstrations which
will be familiar to many from presentation software such as Microsoft
Powerpoint.
This method could also be used to transfer documents from text
to hypertext, as the original document structure could be retained.
Albeit this is a simple structuring method, it retains much of
the strength of hypertext because it uses reference links.
Another possible application area is in instruction of training
documents. Normally teaching material builds on other material,
and a linear structure forces the reader to study the first node
before proceeding to the next. The reader must see the elementary
material first.
There may be a frequent need to present more information in a
single window than usually will be possible in a node. This applies
to documents where the reader logically feels that several activities
are going on in a node. The reader may in such cases feel that
navigation does not exist and/or is illogical (Apple 89, p. 30).
Figure 3.5 shows how such a node would look like. The information
typically comes from specialised hardware such as a CD-ROM player
or a videodisk player, or from a database, e.g. a picture database.
A reader may navigate in the information using typical video-player
controls. Even if the reader is moving around in the information,
he will at all times feel that he is in the same node. Of course,
it may be argued whether this is a node, or if each new picture
corresponds to an independent node, as each node typically is
meant to represent a contained piece of information. Conversely,
it may be claimed that such pictures may often come from static
media from hardware outside the hyperbase itself. Nevertheless,
the reader (and frequently also the author) will perceive this
information as an integral part of the hyperbase. Conceptually,
therefore, single nodes may also be considered as several nodes,
thus having points of similarity with sequential documents.
A special application for the single node is the filter stack
(Apple 89, p. 31). Here the node is used for database queries
for occurrences that satisfy a number of conditions. Such nodes
are often used for species classification, for example determining
plant species (cf. an early software product from Datasekretariatet
[The Data Secretariat] called Dataflora). Each condition,
such as leaf shape or flower colour, is entered in a field on
the screen, and described by means of information objects. The
reader may then change the query conditions by moving in the database
using mouse clicks. When a number of conditions have been selected
the query can be initiated. Figure 3.6 shows a node for determining
mushroom species.
If the hypersystem permits links across documents, a problem will
arise: should the reference node also be visible to the user?
If a node in one document includes a link to a node in another
document, there are two ways of understanding the reference node
document. Figure 3.7 below shows this. Moreover, the information
model may or may not permit links across documents. This is not
feasible in NoteCards, for example.
A database diagram is a graphic presentation of links and other
information units in the entire hyperbase or parts of it, commonly
within one single hyperdocument. The links are usually rendered
as lines between the other information units, which are usually
rendered as "boxes" or as link icons. The other information
units represented in the diagram are most frequently nodes, but
also other information units may be represented, for example hyperdocuments
and other database diagrams.
In some systems, such as Neptune and gIBIS, diagrams are purely
tools, employed by the user when needed, for example the spell-checker
tool in a word processor. In other systems, such as NoteCards
and Intermedia, the diagram is also a separate information unit,
which is represented in the information model along with the other
information units. In the latter case the author may therefore
construct diagrams which are specialised for different uses. Furthermore,
it is frequently possible to perform the same operations on the
diagram, as on the other information units, for example deletions
and additions.
Database diagrams have two main purposes: speedy navigation among
hyperbase nodes and simple hyperbase orientation. A user may usually
move directly in the diagram by pointing at the node he or she
wants to move to. Conceptually, database diagram navigation has
similarities with link following. However, there is one essential
difference. When following links, the user may only move to those
links which are connected to the open node. By navigating in a
database diagram, the user may move to any node in the diagram.
The advantage is that the user can move across larger areas each
time.
Examining the database diagram enhances a user's understanding
of hyperbase structure, thus allowing improved navigation. If
a user has gone to the wrong place when navigating due to orientation
problems, he or she can move directly to the right node. In addition
to diagrams there are also other mechanisms which may reduce orientation
problems.
Database diagrams may permit users to enter editing mode on links
and nodes, e.g. in NoteCards. Some systems also allow user operations
on the hyperbase directly in the diagram, without having to go
to the individual link or node. In NoteCards an author may delete
and construct links and nodes from the database diagram.
The link indications in diagrams may also include further information
than pure structure information. Both NoteCards and gIBIS show
the link type in their link indication in their database diagrams.
NoteCards uses various types of dotted lines, while gIBIS applies
various colours to indicate different link types.
Nodes may be visualised in different ways. A common method is
to render the node as a box with the node name in it. This applies
to the Neptune and NoteCards systems. gIBIS uses various icons
to indicate node types. The node name is placed underneath each
icon. Intermedia presents nodes through the individual node icon
with the node name underneath. Intermedia employs different icons
to indicate the type of information object contained by the node.
There are three usual methods for generating diagrams: manually
constructed diagrams, diagrams generated by the system and stored
statically, and dynamically generated diagrams. Manually constructed
diagrams are made by the author. Typically such a diagram is a
regular node with the chart represented as meta-graphics drawn
by the author.
The second method is to have the hypersystem generate the diagram
and then store this as a separate information unit. NoteCards
uses this method. A database diagram may then be treated as a
regular node. There may be problems if the hyperbase is modified,
as the diagram will then no longer be valid. This can be overcome
if hyperbase modifications automatically trigger updates of the
database diagrams. NoteCards has this feature. If such a feature
is not included in a system, an author should at least be notified
about hyperbase modifications, so he or she can generate a new
diagram.
The third method is generating diagrams dynamically each time
the application is executed. Such diagrams will therefore always
show the actual structure of the hyperdocument, including the
latest hyperbase changes. Intermedia generates a new local database
diagram - see the following section on local diagrams - as the
reader moves around in the document. Another example of dynamically
generated diagrams is found in Neptune, where diagrams are constructed
on the user's request.
However, generating a diagram of a certain size requires much
processing power. The time required to locate all connections
among network nodes in a general network is proportional at N2
+ KN where N is the number of network nodes and K is the number
of edges (Utting, Yankelovich 89, p. 74). If we assume that this
can be transferred to apply to hypermedia, where network nodes
correspond to nodes and network edges correspond to links, this
constitutes the basis for a viable time estimate.
Furthermore, database diagrams do not lend themselves to distributed
environments, where nodes and links may be distributed across
a number of servers, as it will take time to search through several
servers.
In a distributed environment database diagrams require much extra
work, where nodes and links may be distributed across a number
of servers, as it will take time to search through several servers.
One of the systems offering diagrams in distributed environments
is HyperWave.
No special reservations have been made in the preceding sections
as to which parts of the hyperbase are included in the diagram.
However, a hyperbase comprising a number of larger hyperdocuments
may become quite big, making it inappropriate to put all information
units in the hyperbase directly in one, single (global) diagram.
If diagrams become too large, they become hard to read, and hence
lose their value for the user. This has been documented by Utting,
Yankelovich (Utting, Yankelovich 89, p. 62) and by Conclin (Conclin
87, p.39).
It has therefore become the norm to limit the amount of information
to enhance diagram readability. In the following sections we will
examine some of the techniques used, and also some which have
been proposed to limit the amount of information in diagrams.
Limiting attribute values and information content for those information
units which are going into a diagram will reduce diagram size.
Some hypersystems offer the option of restricting the information
amount via query and filtering processes. Using natural language
syntax this might, for example, be "Give me all information
units authored by members of group 5, after 14 November, except
those written by member NN". In Neptune this can be done
directly by the reader. Database diagrams have separate fields
where the user may set valid ranges for information unit attributes
(nodes and links) which are to be included. One drawback of this
system - that the reader does not always know what he is looking
for - has been pointed out by Utting, Yankelovich (Utting, Yankelovich
89, p. 66-68).
In some hyperbases which treat database diagrams as separate information
units, the author may construct the diagram. This ensures that
the user is provided with a diagram containing the relevant information.
However, this is not possible in systems such as Neptune and gIBIS,
which treat diagrams more as special tools.
If the system offers filtering of some kind, this may also be reflected in the diagram. Filtering implies restricting attribute values and information content in the part of the information base which is visible to the user. Only those information objects left after filtering will be included in the diagram. There will be more about filtering in the next lesson.
3.3.2.2 Fisheye database diagrams
Fisheye diagrams have been proposed by Furnas (Furnas 86). A fisheye
diagram offers a higher detail level for those information units
which are closest to the user's position at any time. The closest
area may offer full details including all links and connected
nodes. Farther away, only organisation links may be shown, while
in the most distant parts landmark nodes and links to these will
be sufficient.
Local diagrams show only sibling nodes and their links. Such diagrams
are used in Intermedia, as a consequence of the global database
diagram problems. This diagram tracks user movements, always letting
the user know where he or she may move.
Utting and Yankelovich (Utting, Yankelovich 89) have extended
the local diagram. They have emphasised that a diagram only addresses
some of the orientation problems users encounter. A user needs
additional information about where he or she just came from in
order to avoid going in circles. Moreover, the user must know
when he or she has visited a location. The outcome of this is
an improved diagram for Intermedia, shown on the next page. Using
history and time tracking for the most recent visit are examined
further in the following lesson.
When utilising a number of diagrams, each diagram may offer a
different level of detail for the same information. Users may
use a coarser detail level for a better overview. Coarse diagrams
often display only structure, not giving information such as the
name and types of the information units which are represented
in the database diagram. Using the coarse diagram it is possible
to come up with rough estimates as to the extent of the available
information (Utting, Yankelovich 89, page 66). One possible drawback
to multi-level diagrams is that these in themselves may cause
orientation problems (Nielsen 90, p. 300).
gIBIS uses two-level diagrams, one coarse, one fine. Database
diagrams in gIBIS consist of a window with a large, high-detailed
diagram, and a smaller, coarse-detailed diagram. The smaller diagram
offers an overview of the major part (all) of the base. The big
diagram offers an overview of the user's present whereabouts.
A user may furthermore navigate to another location by clicking
on it.