The look of the link - concepts for the user interface of extended hyperlinks.
The design of hypertext systems has been subject to intense research. Apparently, one topic was mostly neglected: how to visualize and interact with link markers. This paper presents an overview of pragmatic historical approaches, and discusses problems evolving from sophisticated hypertext linking features. Blending the potential of an XLink-enhanced Web with old ideas and recent GUI techniques, a vision for browser link interfaces of the future is being developed. We hope to stimulate the development of a standard for hyperlink marker interfaces, which is easy-to-use, feasible for extended linking features, and more consistent than current approaches.
Figure

1: HyperTIES used cyan to highlight links
[from Shneiderman & Kearsley 1989]
HyperTIES (Fig. 1) avoided this problem by using a distinct
text color for link markers, similar to Hyper-G's
browser Harmony (Fig. 5) which utilized background
colors [Shneiderman & Kearsley 1989; Andrews 1996].
This has the advantage that the typeface and style of the
text can be chosen freely.

Figure

2: Intermedia's link marker arrows
IRIS' "Intermedia" marked hyperlinks with little arrow
icons between lines of text (Fig. 2), showing the start of the
link span but not its endpoint [Yankelovich et al. 1988].
"Emacs Info" brackets link markers with asterisk symbols.
These methods occupy extra screen space and change the
layout of the text by inserting additional elements.

Figure

3: Link markup by the Neptune Document Viewer
[from Delisle & Schwartz 1987]
Bernstein's Hypergate, the Neptune hypertext system (Fig.
and some early Web browsers UdiWWW (Fig.
boxes around the link marker text. This works with the
layout but is quite obtrusive and distracting. An improvement
to this technique could be found in HyperCard and
Storyspace. They drew the boxes only when the reader
pressed particular keys, making links evident on request
thus keeping the text pristine the rest of the time.

Figure

4: Anchor highlighting in UdiWWW
In fact, this was the consensus solution after the Hypertext
'87 demo sessions, when hypertext designers could first
compare all existing systems side by side [Bernstein 1996].
Hiding links has many advantages: pages stay uncluttered,
text stays readable, and page design is less influenced by
link appearance. However, when using "links on demand"
the interface designer must be aware of a potential dis-
advantage: since links are not always visible, possibly
distracting mode switches have to be applied. Therefore
this link trigger has to be seamlessly integrated into the
interface.
A less desirable variant of this method was used by Symbolics
Document Examiner [Walker 1987]: link markers
were hidden so well that they were only highlighted when
the mouse passed over them. This forces a "hunt and peck"
search for active regions. In Microcosm and DLS the user
can query the system for invisible links by marking a word
or some text and then issue a search for matching links
[Carr et al. 1995]. Though anchors are not marked, this
model is well applicable to generic links, given that most
words can be selected as anchors.
Ignoring previous experiences, Mosaic returned to colored
(blue) and underlined text to indicate link markers. This is
not the optimal solution as it emphasizes the link marker
text permanently. The underlined markers stick out from
the surrounding text and decrease its readability as underlining
interferes with descenders, letters that drop below
the line like p, q and j. The blue color is also an imperfect
choice, since especially elderly people have problems to
perceive it; the human eye is less sensitive to the color blue
than to other colors [Lythgoe, 1979]. The reasons for
Mosaic's link marker appearance were obviously of technical
nature: it was quite simple to implement, and at that
time most computers had only 16 colors or a black and
white display. Blue was the darkest of the available colors,
closest to the black text; for monochrome displays, the text
was underlined [NCSA 1996].
The pervasiveness of the Web has led us to accept underlined
colored text as the de facto marker standard for all
mainstream hypertext systems today. It can be found in
help systems on various platforms and even in operating
system components like the Microsoft Windows Explorer?.
Though the use of a standard is desirable from a consistency
point of view, user interfaces have otherwise improved,
and we are still wedged with this historical hack.
More recent technologies like Cascading Style Sheets [Bos
et al. 1998] allow to define the appearance of text links in
various ways. Also, the look of links can be configured
somehow in current browsers, however, the standard
setting is still blue and underlined, and links on demand are
still not possible. Even worse, for the visualization of link
maps in graphics no standard method can be found nor is
implemented in Web browsers. This shows how important
it is to design user interfaces well, considering earlier
experiences, and that even an interface with obvious design
mistakes can become a standard.
ENTER XML LINKING
While the concept of links made it possible to create non-sequential
texts, rich hypertext systems offer a more
sophisticated functionality, i.e., they support comprehensive
structuring, editing and navigation features
[Yankelovich et al. 1988; Bieber et al. 1997]. However, to
date the Web itself only supports embedded one-way links.
This limitation made the authoring of Web pages and the
development of Web servers and browsers simple, enabling
the Web to grow extremely fast. On the other hand, all
approaches that try to integrate some extended functionality
into the Web have to utilize workarounds to overcome the
weaknesses of this simple approach. It was also hard to
compete with the well-known standard browsers, as these
often were better suited to display existing stylishly designed
Web pages.
With the advent of XML linking, the Web will be able to
offer many of the features hypertext experts are missing
today [Vitali & Bieber 1999]. Standard browsers already
migrate to XML and XSLT [Clark 1999] and hopefully
linking will become widely available soon.
The linking potential of XML linking1 is based on two key
standards which are necessary to create and describe links
and link anchors:
XLink itself defines links as relation between resources or
portions thereof. Syntactically, a link consists of an arbitrary
number of resources (local or remote) and arcs. A
resource is any addressable unit of information or service,
while arcs create directed connections between two resources
each [DeRose, Maler, Orchard 2000].
XPointer allows to address different kinds of spans in XML
documents [see DeRose, Maler, Daniel 2001]. They can
vary from points to complex regions and can even be
distributed over the document, e.g. a XPointer could be
used to address the string "Goethe" in all citations in an
XML file:
xpointer(string-range(//cite, "Goethe")).
Two types of semantic attributes are defined: machine-readable
information is stored in the role and arcrole
attributes and the corresponding human-readable textual
information is kept in title attributes. This type information
can be specified for the link as a whole, each
endpoint of a link and for every arc.
linking also presents a solution for linking into other
authors' read-only material, by addressing parts of the
documents' structure. There is no need for tailored target
anchors, which are embedded in the target document, any
more. The importance of this can be seen from printed
media, i.e., referring to distinct pages or paragraphs.
linking may not only be used for hypertext links,
but for any kind of application describing relations,
associations or compositions of XML documents.
However, this paper focuses on its use for hypertext.
To summarize, XML linking will allow a multitude of new
hyperlink features, among them:
? structure and contents may be separated;
links may be bi-directional;
links may be typed;
links may have multiple endpoints;
anchors may be complex or overlap.
While the syntax of XLink has been elaborately defined,
most presentation and behavioral aspects of links have been
deliberately excluded from the model. Only few hints on
how to implement and interact with these features can be
found in the XLink definition, and few ideas exist to enable
the user to cope with this extended functionality. There is a
vague notion of displaying title attributes to enrich link
anchors semantically and computing role attributes to
realize typed links [DeRose, Maler, Orchard 2000]. Pop-up
windows are suggested for links with multiple endpoints
[DeRose 1989; Bosak & Bray 1999]. Though this might
suggest that not much has changed, for the user interface,
these new features create a lot of new questions for link
visualization.
The chances seem to be good that XLink will succeed. The
changes in browser capabilities since Mosaic suggest that
more extensive hypertext features will eventually be ac-
cepted: Forms, JavaScript, Java Applets and Flash animations
are now widely used. Some extended link functionality
is already being simulated with DHTML, showing pop-up
menus with multiple destinations or extra information.
VISUALIZING EXTENDED HYPERTEXT FEATURES
The two well-known hypertext models Dexter [Halasz
1990] and HyTime [Derose & Durand 1994] had features
almost matching, and sometimes exceeding XLink, but no
system ever fully implemented them [Gr?nb?k & Trigg
1999, p. 42]. Nonetheless, many systems existed that were
far ahead of their time and offered functionality that is not
available in the Web today.
This enables us to find ideas and detect problems by looking
at all these systems and how they implemented and
visualized hyperlinks. We map the user interfaces of these
programs to the linking features that are made available
with the introduction of XLink. We can thus discuss what
is needed by the user to profit from the extended functionality

Separation of Structure and Content
Several former Open Hypermedia Systems like Microcosm/
DLS [Carr et al. 1995] or the Devise Hypermedia System
permitted to store links separately
from documents in dedicated linkbases. Likewise,
XLink will allow the separation of structure and content for
the Web.
The external storage of links permits multiple linkbases to
be used for single Web pages. These links may originate
from the original author but also from other authors without
write access to the original document, like a single user or
members of a group2.
The use of several different linkbases can result in an
unintentionally great number of links3. Therefore, the user
must be enabled to select the employed linkbases. An
example for such a method can be found in ?Third Voice?,
a browser plug-in that adds annotations to Web pages4 (Fig.
5). A part of its functionality is a service that adds links
from an external linkbase to keywords. These annotation
link markers are distinguished by orange underlines. Third
Voice offers an extra tool bar in the head of the browser
where the presentation of its links can easily be toggled.

Figure

5: Third Voice adds additional links to an existing
Web page and offers a choice of targets.
Microcosms/DLS already permitted the use of several
linkbases. It offered a configuration screen to select the
utilized link database from a given set [Carr et al. 1996].
Unfortunately this menu was not directly integrated into the
browser interface and the addition of new linkbases was
quite complicated. An XLink browser will also need the
potential to find new linkbases5 and add them to a personal
list. So far, no standard means has been established to do
so.
Bi-directional Links
From the technical point of view bi-directional links help to
links consistent and to avoid broken links. From the
usability viewpoint they also permit to follow links backwards
as opposed to the uni-directional ?goto? links of the
Web. A user could use this feature to find e.g. more recent
information which is referring to an old but valuable
document.
To benefit from bi-directional linking, the user interface
has to support the backward traversal of links. Most hyper-text
systems with bi-directional links like Sepia, MacWeb
or Hyper-G offered a "local map", showing nodes and
connecting links. This visualizes the topology and permits
the user to select source objects directly on the map.
These additional links can be used to annotate and
supplement the existing information with other information
of personal importance.
3 These links may also overlap (see following sections).
Third Voice is available at http://www.thirdvoice.com
5 Furthermore, the primary linkbase will frequently change
when browsing the Web, as it usually will be provided by
the server hosting the current document.
For the Web, the retrieval of links that refer to the current
document poses a serious problem. A prototype Web
browser tool described in [Chakrabarti et al. 1999] gathered
this information from search engines. They alternatively
proposed to extend the HTTP protocol to send backlink
information gathered from the referrer URLs in the server
log. The prototype offered a list of titles of Web documents
that were linking to the current document.
Both approaches have their limitations if the number of
links is high. Especially graphical maps use a lot of screen
space if dozens of nodes and links are displayed. Thus, the
number of objects has to be limited, e.g. by filtering the
most appropriate ones.
Typed Links
A link type describes the relationship between source and
destination of a link, often derived from semantic categories
like "explanation" or "example" [Trigg 1983]. They
were introduced to help users to get a better idea of a link
target. Streitz et al. list semantic link information as their
first principle of useful hypermedia system design [Streitz
et al. 1992]. However, typed links are only helpful if the
user can distinguish the different types.
Tim Berners-Lee's WWW proposal [Berners-Lee 1989]
included typed links, and HTML allows Web authors to set
the link type attributes rel and rev. Though, this feature
is not supported by any current Web browser.
Sepia [Streitz et al. 1992] and MacWeb [Nanard & Nanard
1993] displayed the link type in an overview map close to
the arrow visualizing the link. Once more, this link information
is only available to the user if he considers two
areas at the same time: a document view and a link map.
He has to join these two information segments cognitively.
Other systems use text style to distinguish different link
anchor types: the current Microsoft help system displays
explanatory pop-up links in green with a dotted underline
and uses icons to indicate specific actions as the execution
of a program. However, the potentials of Text style are
quite limited, and inline icons can be distracting and create
problems with the layout.

Figure

Different mouse pointers utilized by the Guide system.
The Guide system utilized different mouse pointers to make
link characteristics apparent [Brown 1987]. The pointer
changed according to the link type if it hovered over a link
(Fig. 6). Since mouse pointers are independent from screen
and text layout, this may be an interesting option for Web
clients, too. Standard software, like word processors and
graphics programs, and also operating systems, commonly
employ these differently shaped mouse pointers as it is possible
to indicate many different actions in a non-obtrusive,
yet immediately visible manner.
Multiple endpoints
Links with multiple endpoints do not connect only two, but
a set of related nodes. Thus different alternative destinations
can be provided. When a user initiates the traversal
of a link with multiple endpoints, he can be requested to
choose between the available options. This solution was
preferred by most former hypertext systems. Microcosm
and DLS presented a list of generated link targets on an
intermediary page as the result of a user query [Hall, Davis,
Hutchings 1996; Carr et al. 1995]. Intermedia displayed a
dialogue box with a list of link titles.
Likewise, the preferred idea for XLink seems to be a pop-up
menu [Halsey, Anderson 2000; DeRose 2000]. Though
lists of targets are probably the most straightforward
approach, they may slow down Web navigation. A user has
to make an additional selection from the pop-up list each
time he follows a link.
Multiple links can also be used to automatically select the
most decent destination by applying a filter. Already the
father of hypertext Vannevar Bush suggested filters for
links. If the user follows a Guided Tour, links of the displayed
documents should be hidden [Bieber 97; Bush 45].
could filter links by link attributes and Hyper-G
by user rights. It would be even more desirable to filter by
semantic criteria like a user's task or profile.
Complex Link Anchors
Many Web usability guidelines confine the setting and the
length of link markers, e.g. Nielsen recommends that link
markers should be about 5 words long [Nielsen 2000]. This
restriction is a concession to the limited link visualization
potentials of current Web browsers, where extended link
spans result in hardly readable underlined text regions.
Hypertext systems that displayed links only on demand
avoided these readability problems.
The XML linking standard allows arbitrary complex link
anchors. As explained before, it is even possible to create
discontinuous anchors, i.e., anchors that consist of several
distinct regions. To the user this may appear like multiple
anchors that share the same destination, which can be
irritating. In Web system evaluations, already links that are
displayed in more than one line have been found confusing,
as the beginning and end of the anchor were not indicated
by the browsers used [Spool et al. 1999].
Consequently, the extent of a link marker should be visuali-
zed. This is possible in recent Web browsers: the link marker
can be highlighted if the mouse hovers over the link.
However, the browser configuration has to be changed or
an appropriate CSS must be defined.
Overlapping Link Markers
Link markers may overlap, either because an author creates
two anchors at two intersecting text sections which are
related to different destinations6, or because other authors
create anchors overlapping with the link spans of the
original author.
Hardly any current Web user will be familiar with the idea
of overlapping link markers as they cannot be found on the
Web or any popular hypertext system. Currently, it is not
possible to create such constructs in HTML, since there is
no way to distinguish different opening and closing anchor
tags. This technological problem can easily be solved even
with embedded links as Hyper-G's markup language HTF
demonstrated. It used link identifiers to associate opening
and closing link tags [Maurer 1996].
Nonetheless it is much harder to find a usable solution for
the visualization of overlapping link spans. Harmony,
Hyper-G's browser, used overlapping colored background
boxes to mark the beginning and end of up to six overlapping
markers (Fig. 5). But even two overlapping links
are hardly readable and this method will finally fail if a
larger number of anchors intersects: the increasing number
of boxes will shrink to pixel height before they finally
disappear.

Figure

7: Link Overlap in Harmony.
The user must also be able to choose a desired link in the
overlapping section. Third-Voice (Fig. 5) displays a pop-up
window where the user can pick the link to follow. Harmony
lets the user first select an overlapping link by single-
left clicks and then follow it by a double-left click
[Andrews 1996, p. 54]. Both solutions are not optimal, as
the first one needs always two and the second one may
even need an uncertain number of clicks to follow a link.
The current version of Hyper-G does not support overlapping
links any more7.
A VISION FOR IMPROVED HYPERTEXT USER INTERFACES
The Web, undoubtedly the most successful distributed
hypertext system ever, has despite its simplicity already
serious usability problems. It must be prevented that this
becomes worse when extended linking features are introduced

We would like to revive a discussion by presenting ideas of
an user interface strategy for extended links. To accomplish
this we consolidated experiences of earlier hypertext
research with established and innovative GUI techniques to
create a consistent vision. These thoughts are widely based
6 Example: the phrase "psycholinguistics department"
might be a link to the department home page, while
another link explains the meaning of "psycholinguistics".
7 HyperWave Information Server Version 5.5 uses HTML
as markup language.

Figure

8: Mockup: Outgoing XLinks can overlap and are marked by transparency. Note the marked scrollbar.
on the analogy of the hypertext reader as a traveler, introduced
in Landow's authoritative "Rhetoric of Hypertext"
paper. He divides the interaction with links into two key
parts: departure and arrival [Landow 1987].
Landow's ideas were based on his experiences with Inter-
media. On the background of later hypertext research and
the enriched linking capabilities of XLink a further discrimination
is possible. The action of departure can be split
into two sub-actions: first, the problem of locating the point
of departure (identifying link markers) and second, the
problem of getting sufficient information about the destination
of the journey (understanding the link relationship).
Considering the arrival procedure, the reader must get a
reception at the destination to understand the extent and the
context of the referenced material. The direction he came
from, i.e., the origin of the journey, is the last page he
visited and therefore known.
Finally, XLink does not only allow for links that connect
just two endpoints ? it is also possible to build XLinks that
represent whole paths or structures. Thus, XLink at last
embodies a standard Web storage format for structural
information, e.g. for guided paths or for hierarchical site
maps. We will discuss the uses of these hidden links (hid-
den in the sense that they are not originating from rendered
page content) in a separate section.
Point of Departure
Current methods of Web authors ? emphasizing text anchors
by using color and style and using specially tailored
graphics to mark graphical link anchors ? are already so
common that they will probably continue to exist when
XLink is introduced. However, as illustrated above, these
methods do not have the potential to identify extended or
externally defined XLinks. Furthermore, no prevalent
standard visualization method can be found to identify
graphical or image map links. Consequently, new schemata
are needed to display supplementary links, e.g. from an
external linkbase provided by an XLink service.
From the usability point of view, a consistent and uniform
technique is desirable, that does not distract from reading
and does not interfere with text and graphical layout tech-
niques, but enables the user to identify even complex
anchors clearly. We think that an appropriate way to
accomplish this might be the use of transparent areas
overlaid on the hypertext document. Overlays have the
advantage to be feasible with text and graphics, indicating
active areas directly by masking them. They can be applied
also at places where the document author did not plan a
link. A possible distraction can be reduced by using soft
and light colors for bright background and shady colors for
dark background. User tests with more sophisticated
transparent user interfaces showed promising results
[Harrison 1995; Cox 1998].
An important factor that has to be considered is link den-
sity. If the ratio of marker area to unlinked area is high, the
distinctive anchor appearance may overwhelm the "normal"
text. Since an arbitrary number of "alien" links can relate to
an XML Web page, a selection mechanism will have to
prevent a phenomenon we would call "link overload",
similar to information overload, which could overshadow
the interaction potentials of the approaching XLink Web.
Therefore, the user interface must provide means to select
which links will be put on view.
Once more, this calls for links-on-demand display techni-
ques. The selection mechanism may be provided by an
additional tool bar or window. A "link database browser"
could be displayed at the left side of the window like the
history list of Microsoft Internet Explorer or the Sidebar of
Netscape 6. The tool would not only allow to select new
link databases8, it would also permit to enable and disable
8 XLink offers a standard storage mechanism for external
links. This permits the construction of hyperbase systems
that offer compiled collections of links, e.g. as the result
of a query [Gr?nbaek & Trigg 1999, p. 167]. These
services could be provided just like today 's search engines
or Web catalogues.
linkbases, making them appear or disappear. Colors may be
used to associate listed linkbases to the anchors on the
screen (Fig. 8).
When a link starts from an anchor longer than a few words,
the overall readability of the text rapidly decreases, at least
as long as persistent highlighting is used. As with the
introduction of XLink source anchors can become arbitrarily
long, this question becomes increasingly important. We
suggest a simple method to reduce the impact on read-
ability: a narrow bar on the right side of the anchored
paragraph. The use of different techniques for short and
long anchors is suggested by looking at the use of conventional
paper: markup on paper consists of highlighting
words by coloring them with a transparent marker and,
when longer passages need to be distinguished, marking
whole paragraphs by using vertical lines on the page
border. Sometimes a title is given to help recognize the
underlying concepts of the passage. Markup of this style
has the advantage to be apparent but not as distracting as
long underlined text. It uses only little screen space and is
goes along well with most layouts.
Since this simple technique does not show the exact location
of link marker start and end, it should be supplemented
by a rollover effect. The scrollbar, or optionally a small-scale
overview window could be used to show the location
of link anchors that are outside the currently visible page
section. Using the scrollbar to locate particular areas on
long Web pages was already suggested by [Laakso, Laakso
Overlapping links of several linkbases could be visualized
by transparent overlays in a defined neutral color, like
bright gray. If the user clicks on such an area, a transparent
pop-up appears, showing a list of the available link titles in
the color of their associated database. Moving the mouse
over these transparent items will highlight the related link
markers in the document.
Destinations
At first sight the more or less uniform looking links of the
Web are not typed. Apart from the marked text, the only
preview a user can always get in a Web browser is the
destination URI [Spool et al 1999]. Even this scant information
is frequently utilized by Web users. Sometimes link
titles or alternative descriptions to graphics are provided to
hint at the content of the target document.
Looking closer the current Web could already provide
much richer information. Link targets can differ in type
("mailto:" links, downloads), availability (broken links),
size, and connection speed (affecting download time).
Further information of semantic nature like title, author and
language of the target document or structural hints like
indicating out-of-site links could be used to automatically
enhance link preview. In a paper on our project HyperScout
we already suggested techniques to display such information
in pop-ups [Weinreich 2000].

Figure

9: A pop-up menu that renders both XLink-specific,
and other automatically gathered information.
While XLink's title information can also be straight-forwardly
displayed in such a pop-up window, the
machine-readable information is provided to compute type
information. This can be used to induce alternative traversal
behavior, or to get advance information about file
types of target documents. It could also be used to filter
links according to a specified user profile. If this leads to
alternative browser behavior, this must not be hidden from
the user. In addition to pop-ups, we suggest the use of
different mouse pointers to immediately indicate link
actions, comparable to the method of the Guide system.
If an XLink offers several destinations, the problem of
selection occurs. Pop-up menus with a list of available links
are suggested in the XLink definition and some publications
[DeRose 2000; Bosak and Bray1999]. They have,
however, the disadvantage to require additional user action:
the user has first to choose a link, click and then he has to
choose a target anchor and click again. We would suggest
to use the role attributes to allow filtering, thus displaying
only part of the link targets available. In certain cases it
might even be desirable that a default destrination is automatically
selected when the left mouse button is clicked.
Indicated by the mouse pointer, a pop-up appears only on
right mouse click, presenting a choice of complementary
link targets.
Arrival
The rhetoric of arrival in the sense of Landow requires that
the reader gets the feeling of welcome at the destination
document: ?One must employ devices that enforce hyper-text
capacity to establish intellectual relations.? [Landow
1987].
Establishing such an intellectual relation requires the user
to determine the target of a link and its context. The method
of today's Web browsers to present the target is simple: the
whole document is shown, or, if a fragment identifier was
specified, the browser tries to scroll to the position of the
fragment anchor. In fact this is a known usability problem
of the Web: as the span of the link target is not visualized
the user cannot identify the extent of the destination. If the
fragment locator is near the end of a page, the browser
often cannot scroll sufficiently down to display the link
target at the top of the window.
Tim Berners-Lee's first graphical Web browser on the
NextStep system and later versions of Mosaic did already
highlight the target anchor [Caillau & Ashman 1999], a
feature lost in current mainstream browsers. Since we
already suggested transparent highlighting areas to identify
starting anchors, a different method would be advisable to
prevent misconceptions.

Figure

10: A mock-up showing the incoming link target in its
context and information about co-references.
We again suggest a technique long before known to work
on paper: lateral marker lines. A narrow bar on the far left
side of the window is used to indicate the target span. The
chance of confusing incoming and outgoing links is thus
(incoming links: left vs. outgoing links: right) kept to a
minimum. The Devise Hypertext System utilized a similar
technique to indicate target anchors [Gr?nb?k & Trigg
1999, p. 314]. When a more precise visualization of the
target becomes necessary (e.g. for tables), an on-demand
method may be used: moving the mouse over the marker
bar will shade the rest of the document except for the target
area; a method already used in Harmony's PostScript
viewer [Andrews 1996].
If the target section is larger than the visible window,
clicking on the bar will ?pin? the shading and the user may
scroll the page. Additionally, the scrollbar may be used to
show the extent of the target span compared to the whole
page, especially useful if it does not fit into the window.
Although a very precise notion of the target anchor can be
specified with XML linking, a weakness of XLink
emerges: what the standard lacks, is a definition of the link
context. Nanard and Nanard argue for a distinction of link
anchor (as trigger) and link context (as minimum reading
context) at both ends of the link. The link anchor is usually
quite short and focused, as the link context is embedding
the anchor, enabling the reader to understand the relationship
of a link better [Nanard & Nanard 1993; Hardman et
al. 1994]. The meaning of a sequence of words can change
severely when torn out of its context, i.e., the surrounding
sentence, paragraph or chapter. XLink misses an explicit
definition of such context spans. This is a serious dis-
advantage, that could be easily fixed by an additional
attribute for the resource tags. Then, if an anchor is
selected, the context should be made visible.
It is also sometimes useful to supplement other links
pointing to the target anchor, called co-references. These
links could have been collected in earlier sessions, retrieved
from search engines or compiled by linkbase systems. They
can stem from material that was not visited in the course of
the current search, and, if followed in the reverse direction,
they can provide material related to the current target
anchor.
We suggest to make the most appropriate co-references of
the last navigated link available by right clicking on the
lateral marker bar, just as the right click opens a pop-up on
link anchors. A double click can be used to open a larger
list in the left side of the browser with more references
pointing to that document. Finally, we think it would be
feasible to apply filtering mechanisms utilizing the arc
roles, e.g. to display only links that use the current anchor
as an ?example?.
The Use of Hidden Links
So far we have tried to optimize the visualization of hyper-links
with markers in documents. However, XLink can also
be used to describe relations without markers, e.g. non-associative
structural XLinks. These links can either be
supplied by the author of a site or by an external source,
e.g. a guided tour or a trail [Hammond & Allinson 1987;
Bush 1945]. Automatically generated link overview maps
(local map, fisheye view, 3D landscapes) often seem to be
more confusing than helpful, when used in large hyperspaces
[Utting & Yankelovich 1989]. Because of the
immense size and the distribution of the Web, structural
information has to be provided for an overview that truly
can help to find semantically related content.
A special link type introduced by HTML 2.0 (<LINK
REL>) to distinguish between structural and associative
links [Berners-Lee 1995]. Though this made it possible to
separate structure-related and content-related navigation, it
is poorly supported by current Web browsers. Only some
less widely spread browsers like Lynx and iCab (Fig. 10)
support the use of structural links. Thus, so far there are
only a handful of Web sites that offer structural links. Yet,
this information could often be easily provided, especially
for generated Web content or sites created with an authoring
tool.

Figure

11: iCab's structural link navigation toolbar.
To support structural information in XLinks special link
roles and arc roles would have to be defined. This, how-
ever, would use the role attributes not for semantic but
rather for syntactical information. Then again, it would be
possible to provide complete structures, e.g. Guided Tours
or Site Maps, in a single link, something not possible with
the LINK element.
As for link markers, a consistent interface is needed for
structural navigation: we suggest that XLink-aware browsers
should provide an iCab-like toolbar for basic structural
navigation. Furthermore a hierarchical view, like Hyper-
G's collection tree browser, can be provided on demand.
This additional navigation tool should be displayed in the
same browser window, e.g. in place of the sidebar. The
interface should also provide a standard interface for
Guided Tours or other meta-structures, thereby eliminating
the need for workarounds.
We can also imagine hybrid XLinks which bear structure,
and have link markers in the Web page9. This implicit
structure could be extracted and displayed in the standard-
9 Such structural links include: links on a homepage
pointing into the site, site logos pointing to the homepage,
arrows for next and last pages, etc.
ized user interface. The original embedded links should not
be hidden: the user can thus either use the consistent
standard interface (without having to search for navigation
or follow the rendered structural links (without
having to leave the page context).
CONCLUSION
Usability has become a key factor for the success of soft-
ware. Despite the intensive research on hypertext systems,
no standard hyperlink user interface has been agreed on.
We are thus bound to the de-facto standard of the Web, a
design with many inherent weaknesses that does not agree
with extended linking features.
Experiences from software engineering have shown how to
do better: the initial design of a system has to include its
user interface as well as its functionality [Nielsen 1993].
The representation of data is only of secondary importance.
This demonstrates the need of reconsidering currently
developed standards: the XLink standard does hardly
mention the user interface. The same lack of consideration
of link interfaces is apparent in other W3C activities:
Neither HTML nor its present descendants nor other
standards like SMIL or the Semantic Web Initiative mention
design issues regarding the user interface.
In this paper we try to stimulate a discussion on the visualization
of and the interaction with extended hyperlink
features. We believe that this is necessary to prevent an
impairment of Web usability when new linking features are
introduced.
Experiences from historical systems can help to avoid
mistakes and to provide solutions that are still topical. This
paper presents problems and solutions for the presentation
of and the interaction with extended hyperlink features.
Though we are aware that the developed vision can still be
enhanced, we gathered well-tried methods to create a consistent
and easy-to-use interface.
In this process, design issues for XLink arose: we found
some open issues, i.e., the missing definition of contexts,
default arcs, syntax attributes or attributes needed to carry
preview information (like the size of a target document).
Some issues were completely left out, like the distribution
of links via linkbases or an exact specification for the use
of the semantic attributes.
Nonetheless, XLink can be used even today: when XLinks
are used on Web servers, the centralized storage makes link
management much easier [Markos 2000]. Using XSL
Transformations, XML or XHTML documents and XLink
linkbases can be converted to HTML and be accessed by
conventional browsers ? right now.
In the long run, however, this functionality should be
moved to the client ? only then the browser will be able to
exploit the full power of XLink. The success of XLink or a
similar standard will eventually depend on two factors:
decent tools for authors and readers.


--R


Information Management: A Proposal.
Hypertext Markup Language - 2.0
HypertextNow: Showing Links
Forth Generation Hypermedia: Some Missing Links for the World Wide Web.
Cascading Style Sheets Level 2 Specification.
XML and the Second-Generation Web
Turning Products: The Guide System
As We May Think
Hypertext in the Web
The Distributed Link Service: A Tool For Publishers
Web Links as User Artefacts
Surfing the Web Backwards
XSL Transformations (XSLT) Version 1.0
XML Path Language (XPath) Version 1.0
Hypertext: An Introduction and Sur-
The Usability of Transparent Overview Layers.
Neptune: A Hypertext System for CAD Applications
XML Pointer Language (XPointer) Version 1.0
Linking Language (XLink)
Making Hyper-media Work: A User's Guide to HyTime

The Dexter Hypertext Reference

XLink and open hypermedia systems: a preliminary investigation
The Travel Metaphor as Design Principle and Training Aid for Navigating around Complex Systems.
Adding Time and Context to the Dexter Model
An Experimental Evaluation of Transparent User Interface Tools and Information Content

Relationally Encoded Links and 46.
The Ecology of Vision
--TR
Neptune: a hypertext system for CAD applications
Hypertext: an introduction and survey
The travel metaphor as design principle and training aid for navigating around complex systems
Hypertext hands-onMYAMPERSANDmdash;an introduction to a new way of organizing and accessing information
Context and orientation in hypermedia networks
SEPIA
Should anchors be typed too?
The Amsterdam hypermedia model
An experimental evaluation of transparent user interface tools and information content
As we may think
Fourth generation hypermedia
Fluid links for informed and incremental link transitions
The usability of transparent overview layers
Web site usability
Surfing the Web backwards
Turning ideas into products
Document Examiner
Relationally encoded links and the rhetoric of hypertext
XLink and open hypermedia systems
Hypermedia on the Web
Hypertext in the Web MYAMPERSANDmdash; a history
Concepts for improved visualization of Web link attributes
Designing Web Usability
Hyperwave
Usability Engineering
Rethinking Hypermedia
Making Hypermedia Work
A network-based approach to text handling for the on-line scientific community

--CTR
Duncan Martin , Helen Ashman, Goate: XLink and beyond, Proceedings of the thirteenth ACM conference on Hypertext and hypermedia, June 11-15, 2002, College Park, Maryland, USA
Duncan Martin , Mark Truran , Helen Ashman, The end-point is not enough, Proceedings of the fifteenth ACM conference on Hypertext and hypermedia, August 09-13, 2004, Santa Cruz, CA, USA
Paolo Ciancarini , Federico Folli , Davide Rossi , Fabio Vitali, XLinkProxy: external linkbases with XLink, Proceedings of the 2002 ACM symposium on Document engineering, November 08-09, 2002, McLean, Virginia, USA
Hartmut Obendorf , Harald Weinreich, Comparing link marker visualization techniques: changes in reading behavior, Proceedings of the 12th international conference on World Wide Web, May 20-24, 2003, Budapest, Hungary
Delfina Malandrino , Vittorio Scarano, Tackling web dynamics by programmable proxies, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.50 n.10, p.1564-1580, 14 July 2006
Niels Olof Bouvin, Augmenting the web through open hypermedia, The New Review of Hypermedia and Multimedia, v.8 n.1, p.3-25, January
Whitehead, As we do write: hyper-terms for hypertext, ACM SIGWEB Newsletter, v.9 n.2-3, p.8-18, June-October 2000
XLink;user interface;distributed hypertext;link marker