Navigation.html
7.29 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
<title>
HyperText Design Issues: Navigational techniques
</title><!-- <NEXTID N="13"/> -->
</head>
<body bgcolor="#FFC060" text="#302005">
<a href="OldDocs.html"><img src=
"../Icons/WWW/arch1990" /></a>TimBL
<hr />
<h1>
Navigational Techniques and Tools
</h1>
<address>
<a name="anc5" href="../People.html#BernersLee" id=
"anc5">TBL</a>
</address>There are a number of ways of accessing the data one
is looking for. Navigational access (i.e., following links) is
the essence of hypertext, but this can be enhanced with a
number of facilities to make life more efficient and less
confusing.
<h2>
Defined structure
</h2>It is sometimes nice for a reader to be able to reference
a document structure built specifically to enhance his
understanding, by the document author. This is especially
important when the structure is part of the information the
author wishes to convery.
<p>
See a <a name="anc2" href=
"../../Conferences/ECHT90/Structured.html" id="anc2">separate
discussion of this point</a> .
</p>
<h2>
<a name="anc6" id="anc6">Graphic Overview</a>
</h2>A Graphic overview is useful and could be built
automatically. Should it be made by the author, server, browser
or an independent daemon?
<p>
Can one provide an overview with less granularity than the
basic web by grouping nodes in some way? The user could
select from <a name="anc3" href="Topology.html#4" id=
"anc3">link types</a> used to imply the tree
structure.<a name="anc4" href="../People.html#groff" id=
"anc4">(JFG)</a>
</p>
<p>
I think this depends on how long it will take. It might be
interesting to experiment with daemons which will
independently make and update maps of the web. This is not
essential for a first pilot model.
</p>
<h2>
History mechanism
</h2>This allows users to retrace their steps. Typical
functions provided can be interpreted in a hypertext web as
follows:
<dl>
<dt>
Home
</dt>
<dd>
Go to initial node
</dd>
<dt>
Back
</dt>
<dd>
Go to the node visited before this one in chronological
order. Modify the history to remove the current node.
</dd>
<dt>
<a name="z12" id="z12">Next</a>
</dt>
<dd>
When the current node is one of several nodes linked to the
ªbackº node, go to the next of those nodes. Leave
the ªBackº node unchanged. Modify the history to
remove the current node and replace it with the "next" (new
current) node.
</dd>
<dt>
Previous
</dt>
<dd>
When the current node is one of several nodes linked to the
ªbackº node, go to the preceding one of those
nodes.
</dd>
</dl>In many hypertext systems, a tree structure is forcibly
imposed on the data, and these functions are interpreted only
with respect to the links in the tree. However, the reader as
he browses defines a tree, and it may be more relevant to him
to use that tree as a basis for these functions. I would
therefore suggest that an explicit tree structure not be
enforced.
<p>
(If a default tree is needed by the system for some reason,
then we can always use the creation order: when a node is
created it is always created with a link to an existing node.
Such links, whatever their type, may be used to define a
tree. If they are deleted, an alternative link must be chosen
to become a tree link.)
</p>
<p>
If authors want to write a tree structure into their
documents, then the words "after", "before" and "above" could
be used to mean a static structure.
</p>
<h2>
Intelligent navigation
</h2>See A. Secret's <a name="z11" href=
"Intelligent_Navigation.html" id="z11">discussion of
intelligently navigation techniques</a> .
<h2>
<a name="anc8" id="anc8">Index</a>
</h2>An Index helps new readers of a large database quickly
find an obscure node. Keyword schemes I include in the general
topic of indexes. <a name="anc9" id="anc9">The index must, like
a graphic overview, be built either by the author, or
automatically by one of the server, browser, or a daemon</a> .
The index entries may be taken from the titles, a keyword list,
or the node content or a combination of these. Note that
keywords, if they are specifically created rather than random
words, map onto hypertext ªconceptº nodes, or nodes
of special type ªkeywordº. It is interesting to
establish an identity relationship between keywords in two
different databases -- this may lead a searcher from one
database into another.
<p>
Index schemes are important but indexes or keywords should
look like normal hypertext nodes. The particular special
operation one can do with a good keyword index system which
one can't do with a normal hypertext system is to do a fast
search on multiple keywords. This must to be provided as an
extension to the hypertext navigation scheme. However, it is
in fact analogous to a trace starting with more than one
node, which is a valid hypertext tracing operation. The
difference is that the tracing would normally be done by a
browser, but the indexed search done by the server.
</p>
<p>
When many nodes in a web represent different indexes, then a
query search can chain between them (See " <a name="anc7"
href="ManyIndexes.html" id="anc7">Web of indexes</a> ").
<a name="z10" href=
"http://www.vuw.ac.nz:80/who/Nathan.Torkington/ideas/reggie.html"
id="z10">Nat Torington's musings</a> .
</p>
<p>
See also: <a name="anc1" href=
"../../Conferences/ECHT90/HTandIR.html" id="anc1">HyperText
and Information Retrieval</a>
</p>
<h2>
Node Names
</h2>These allow faster access if one knows the name. They
allow people to give references to hypertext nodes in other
documents, over the telephone, etc. This is very useful.
However, in Notecards, where the naming of nodes was enforced,
it was found that thinking up names for nodes was a bore for
users. KMS thought that being able to jump to a named node was
important. The node name allows a command line interface to be
used to add new nodes.
<p>
I think that naming a node should be optional: perhaps by
default the system could provide a number which can be used
instead of a name.The system should certainly support the
naming of nodes, and access by name.
</p>
<h2>
Menu of links
</h2>Regular linkwise navigation may be done with
ªhotspotsº (highlighted anchors) or may be done with
a menu. It may be useful to have a menu of all the links from a
given node as an alternative way of navigating. Enquire, for
example, offers a menu of references as the only way of
navigating.
</body>
</html>