2. Making Images of Structure

HTML is commonly said to be a non-linear medium which frees its readers from sequential presentation of material, allowing them to pursue threads of associations as if swinging from vine to vine in a jungle of information. Consequently, it is not recognized that HTML can constrain the order of reading even more severely than does the medium of print. That is, if you links a set of pages with only a "next" link between each, you force the reader to begin at the beginning and browse in order--no flipping ahead! "Presentations" at conferences or business meetings are also linked Next/Previous and that is that. To my surprise, several of my students when offered a chance to write "hyperfic" wrote such chains, producing very traditional little narratives. Siegel calls this arrangement a train or a tunnel. Much of the artfulness and effectiveness of stories arises from the order of telling, of course--more so, probably, than for a number of other types of discourse, though order of presentation has long been a focus of discussions of argument as well.* And similarly for didactic texts, parts of which are more or less unordered exposure to what there is and parts of which are more consecutive and incremental.

When order is not particularly crucial to the intended effect of the document (as in online documentation) and the length of the document has grown to the point where serial scrolling is cumbersome, one expects a Table of Contents and some means of entering the document from "lower down" (that is, skipping down and entering from the side). Linking from a "menu" to subsections has been a common use of hypertext in documentation since the beginnings of the Info system on Unix.

Along with the Menu-subsection navigation came a primitive Next/Previous, Up and Top options that probably gave hypertext a reputation for disorienting its users that many have yet to recover from. These options resembled nothing so much as the N, S, E, W (and maybe Start) move options of a dungeon-type maze, in which working out the groundplan by stumbling through it was the essence of the game. "You are in a dark chamber with a small window high off the ground. What do you do, player_name?" The great navigational breakthrough of Mosaic, Lynx, and then Netscape was the Back button/arrow/option. "Previous", be it noted, was not the last place you were, but the sister node to the left of the one you were at, or, if you were at the leftmost, then the left sister of the node above you (i.e., your aunt to the left). To define a history Object for the browser window that kept track of the URLs previously visited was a stroke that made HTML navigation far more intuitive than the Info options--intuitive, that is, because it allowed readers to re-trace the path that they had followed, episodic memory being the basis of much of our navigation, not manouvering according to some menu or map given at the "top". (The "back" button was of course also crucially necessary to get back from files on remote computers--a possibility that did not cross the minds of the original inventors of Next/Previous/Up/Top.)

"Back" by itself lets you retrace a path, but it doesn't help locate you in terms of the over-all site structure. For that, we may still want a graph representation of the structure, even if it is only a list of headings/topics. I find that many beginners go through a "frames" stage as their pages begin to include more and more, and they want a TOC to point up the structure. The most common use of frames is to set up a left TOC column with a TOC full of hyperlinks that trigger the presentation of files in a "main" or "viewer" target frame in the wider right column. This way, the menu remains visible and always available for navigation. And similarly, as JavaScript and Java develop, they offer much used "remote" floating menu and control panels that pop out upon entering a page--things like the simple TOC that should have come up when you opened this page.

The best of these update your location (your "currently selected") as you move about the site. Again there is an analog to the world of computer games, which is that of the maps and other perspective views that you can access in, say, a Doom-type 3D maze. I think that this desire to see the part in relation to other parts within a whole is a not just a matter of being able to find and retrieve information quickly but is a kind of knowledge or understanding in its own right.

This "remote" is very simple, of course, and the understanding of the subject it contains is hardly overwhelming, but sites are likely to develop branchings off of the main nodes and crossing paths that require more detail and articulation in the overview. But what kind of overview? We stand here at the threshold of the Visualization of Information, a rapidly developing area which begins with hierarchies and outlines, and ends cruising in 3D virtual information landscapes. Before we take up mapping the relations of the parts and basic units, however, we should address the question of what are the basis units ("nodes") which are the locations in the information landscape.

The standard line in HTML handbooks about whether to put chunks of text in internal sections (i.e.--NAME attributes in tags) of one file or in separate files is that either choice is ok, although separate files are preferable to minimize downloading time for the first part of the file.* Even if they end up downloading the whole thing, they will have had an early taste and will have chosen to wait for more.

They recommend making the first page a master index to the collection of linked pages. . That is, our simple TOC list would be the main contents of the home page and each item in it would be a link to another file. There are further costs and advantages, however, to each mode that only emerge when the site becomes big enough to need the tools mentioned above. Three points favor one, subdivided file:

• all the components stay together in one file, making for easy up and down loads;
• the entire file is accessible to the browser's full text search engine;
• the file can be scrolled through as a continuous document, backing up other navigational schemes.

Of course this last may not be an advantage if you want to break with the traditional article format and its implied start-to-finish reading and to force hypertext navigation. Also, useability studies have suggested that people don't like to scroll. On the other hand, one may match these with three advantages of separate files:

• you can monitor accesses to the separate files;
• the entire site can be indexed with one of several free indexing programs;
• having file structure match linking produces produces a Table of Contents that more directly reflects link structure (of this more below)*.

Your decision on this point is not a once-only one: mixed systems are possible and you can change, but you should be warned that changing after you are fairly well into a project will break a lot of links. This is one reason people want programs to map and analyse the structure of their site. It is interesting to note that latex2html, the very powerful program for converting LaTeX marked documents into HTML marked ones, will produce one file per section or one big file with many subsections as the user chooses.

2.2 Supposing then that, whether for orientation or accessing information--or for your own analysis of a complex web site-- that you decide to display the parts and relations of the parts in your site with some sort of site map or TOC. There are at least three kinds of structures you might use:

• an actual directory and file name,
• a topic outline, or
• a link map.

An actual directory map is rarely used because it is not very illuminating. Most net sites having fairly flat directory structures with a couple of subdirectories for pictures or sounds. Put another way, the directory structure is what a browser displays when you link to a site with no target file and with no index.html to steer readers to the proper top file of the site--other people's actual site directories are about as messy and cryptic as mine. A map of directories and file names is topographically accurate, assuming that file directories define locations in some basic virtual space.

A topic outline indicate the logical relations between files (or nodes) in a topological map such as an outline. We have all used topic outlines since grade school, usually of the I-II-III variety, but perhaps later of the quasi-decimal style. The topic heads and subheads refer to sections of documents that may be marked by name or number, but only have to support link targets: either NAME anchors (within a document) or file URLs can serve as targets for the topic name anchor in the TOC to the section of text to be displayed. Thus the topics and subtopics of a site may be all found within one document or spread over several documents. A topic outline is understood to properly partition the site (a place, and only one place, for each basic chunk of text in the site): text ranged under one topic cannot simultaneously be under another topic or subtopic as well. It is important to get very clear about topic structures because link maps are often made to resemble them, but are in fact quite different formal objects.

Link maps graph navigational dependencies: that is, they represent possible paths from one file to others followed by clicking hypertext links. The files so linked may not be in the same directory, or even on the same computer. Most link-mappers, if so instructed, will follow links onto remote sites, and from there to wherever they lead.

Trees (which is to say rooted, directed graphs) are associated with hierarchy, and hierarchy in information can range over:

• taxonomies (e.g. of animals),
• geneologies (e.g. of homo erectus or of persons),
• order of report/command (e.g. the organizational chart), and
• sentence constituency (e.g. the tree diagram of generative grammar).

As a general descriptive term for the tree relations we speak of parent/child/sibling relations; it would be difficult to identity a constant semantic value for the "child of" relation across all of these types of trees, since it goes from:

• "kind of" to
• "descends from" to
• "reports to" to
• "is a constituent of".

Generally a child may not have multiple parents* That is, branches cannot reconverge, or else you would be taking orders from two different people, you would be a member of two (or more) different species, etc. So parent-child is the core structural relation in a tree, and the reason the asymmetry of "parent/child" is invoked is that links are directional: you can traverse a tree from root to branches to twigs and leaves but not in the reverse direction. To be sure, we might annotate the links for type of connection, which would be a partially interpreted tree. Although something like this is done in the semantic networks of NLP, it is not common in tree diagrams which generally leave the links untyped in the diagram.

In relation to informative texts, the standard topic outline is a display of this kind, where "child of" is most often "specification of"; other bases for dividing a topic are possible in say historical narrative or argument or more formatted genres. A technical document with hierarchical numbering of sections gives each section an index in the overall outline, maybe even a section name, in which case the outline is embedded in the text (or vice versa). With numbering in, the TOC for this site looks as in the margin; here the links all go to "NAME" subsections of a single document. Since these sections and subsections are located in one document, the hierarchy does not mirror the file directory structure. This would be true even if they were separate files, but in the same subdirectory, or if they were mixed, some sections of one file, others of separate files.

Perhaps the "easiest" representation of topic/sub-topic relations is the increasingly popular drop-down menu; "to save a file, pull down the File tab and click on Save". No problem grasping the rationale here: saving is clearly a file operation, as is printing. And there are no implications of the topic as some sort of place where Save is located--only that to "get to" Save you have to "go through" File (if you don't know the speed key combination).

Nested boxes have essentially the same meaning as trees, and even insist more strongly than the tree on the imagery of subparts as "included in" (rather than say "under") the more general headings. Here is a site we will model repeatedly, this time displayed with boxes:*

And of course the boxes can easily become cubes or rectangular prisms, as in Jun Rekimoto's imagemap of his own directory at Sony Research:

Well and good, you may say, but what of hypertext linking as a way of organizing a text? Is it, as the early hypertext celebrants said, always associative, side-branching, and a odds with the orderly array of the hierarchy?*

What we think of as the classic hypertext link is a cross reference or citation out of one place in a text to a place elsewhere in the text or in another text--a jump, as it was sometimes called. But of course in online text the move from topic to subtopic is also done by a hypertext link, so that a map of the hypertext links in a site would not be so wildly different from a topic outline, just richer. It still makes sense to think of all the hypertext links in a site as steming from the initial entry point and taking us by one or more stages to other places. Links combine in chains to give patterns of "flow" because standard HTML links are one-way. When we are out of the train tunnel, and files have each two or more links to other files, the pattern of links has a branching structure too, and is frequently displayed in the form of an outline tree. Most pages, even the webbiest, begin somewhere (at a home or top or title page); all chains or paths of links begin there, and we can trace how many links away a certain page is (note that link mappers typically display links between pages, not between sections of the same page). The button will open a somewhat edited link map of my site Phonetics Resources based on one produced by the web analyzing program inWebstigator--now called WebAnalyst^fn

Note: Mapping programs sometimes consider local to be "having a relative URL", but one can of course use full (absolute) URLs as well for files in your own directories, so a mapper that checks the URL of a file against that of the current directory before classing it as "remote" has an intelligent feature.

In this and most of the other maps to follow, we are only concerned with links to local files; I turned off the "follow external links" option, so that the presence of links to remote sites is ignored. Further, I omit all non-text files since they are never the source of links and clutter up the picture considerably. There is nothing hard and fast about the external/local distinction: I often download and place on my site files I want to be sure everyone can access without touring off site. So these map as local, but are not texts written by me.

Warning: Link following programs typically do read image maps correctly as a set of links to other files or sections, but do not read the Javascript "window. open" command that is attached to the buttons of this document, and so do not record the files displayed in those windows as links (they do not use "href"). The standard hotlink anchors that open windows here use "href=JavaScript:" and hence are counted as links by some link-followers, not counted as others, and counted optionally by the best ones. In effect, it is as if opening another window is not path-following, which classically involves the replacement of the material in your browser window with the material at the target of the link. Consistent with this rationale, link mappers do not count a link to a subsection as a change of level or depth: you don't have to change documents to get there.

Such a view is consistent with one way of valuing hypertext for foregrounding the desired bit of information and placing the surrounding bits off-screen, as it were (cf. Jorn Barger). On such a view, the method used in this document of opening multiple windows and letting the reader decide where to put and when to close them would be contrary to the nature and purpose of hypertext

This diagram is produced by a link-following procedure that follows a link to another file, then records the file and follows the links from that file to the next ones. I then edited the output to make the main subdivisions of the top document separate heads.

I call this a Webiarchy because it looks reassuringly like the outline tree we started with, but it relaxes some of the constraints of the standard topic hierarchy. The relaxations are two. First, it includes "returns" (here links looping back to the top file), though they are not indicated as such. So if you didn' t pay attention, you wouldn't see that the "Studying Phonetics on the Net" links rather deep down are returns to the top file. That is, what appears as a child is in fact an ancestor. Second, a Webiarchy can have the same file appearing in more than one place (a child of diverse parents). This is the case with the "IPA Transcriptions" file, which is linked from two different places, and the "Sound to Graph" file that is a cross-reference with a single "return" to one of the referring files. Such cross linkage gives us a lattice graph where branches can reconverge. Handling this by multiple mention of a file fails to represent the sense of paths intersecting and reconverging-- that the multiply-mentioned file is the same point in relation to where you can go next (unless you use the Back button to retrace your path, which would take you different places, depending on how you got to this point). (This is true of course also for the Nested Boxes display, where you can see the same multiple placement of those files.)Note that the result of these relaxations is that some files do not have a unique address within the webiarchy.

A number of link mapping programs emulate the now familiar Windows 95 Explorer directory display (itself developed from earlier systems on other operating systems) with its opening and closing folders. This system is clear and pleasantly interactive as a way of visualizing a file directory structure, but as a way of visualizing a webiarchy, the file-and-folder metaphor is very mixed. It has no problem with multiple membership for a file, since we often have copies of a file in more than one place and, if you are a Unix user, you even have symbolic links which, when followed take you to a different place in the file hierarchy. But file-and-folder is also misleading, for a webiarchy does not specify the location of files within a tree of file containers (folders); rather, it locates files in relation to others that they link and are linked by. Put another way, folders (the manila kind) are nothing but containers for files, whereas when you use folders for branching nodes in a Webiarchy, they can be files from which other files can be reached by hyperlink. So the meaning of folder becomes "that which branches" or "parent." And hence the meaning of file is "that which does not branch/link"--i.e., a cul de sac. This is odd. In addition, the file-and-folder metaphor is incomplete, as it does not offer much of a way to indicate that a file can be reached by more than one path (and is a point of convergence of paths), nor does it have any natural way to indicate the looping back of returns.

Note:The most extreme use of the f-and-f metaphor I have seen is in the "tree display" navigator window in the Multidoc Pro SGML browser for Windows 95 (see left column), where the folders are used to represent the elements of markup (such as P or BLOCKQUOTE or H1) which do not themselves directly contain content data ("text" , images, sounds, flics).This use does preserve the sense of "folder" as not containing directly any displayable content, which is more than you can say for f-and-f imagery in a webiarchy, and SGML/HTML markup trees do not reconverge or loopback.

One way of making apparent these special properties of a webiarchy is to highlight the multiply-appearing files in green (or some other color) and to mark the loopback "returns" with a reverse arrow, so:

Ideally, each pair or set of identical files would be given a different color--color-coding cross-reference and return. Microsoft's SiteAnalyzer uses color green for a file reachable by multiple paths and may also use (in the file-and-folder display) link icons with arrows coding whether the link is upward or downward in the file hierarchy or on the same level or even on the same page (as a NAME subdivision). But SiteAnalyzer still cannot show the multiple connections.

An alternative to such a hybrid would be something that is still a parent/child directed tree, but one that uses arrows and allows return arrows and converging arrows. Such a display is possible with the data visualizing program for XWindow daVinci ^fn. The arrows are the equivalent of a one step indentation. If we place the initial point at the left margin, the figure suggests a flow diagram. Here, for example, is a snapshot of a daVinci tree of the same link pattern oriented on its side with the same color coding for depth of linking as above.

The arrows do capture directions of flow (i.e., possible sequential chains of browsing), but the visual implications of a flow diagram are mixed. Flow diagrams are goal directed--in some sense the file nodes at the end of the chains are what you are trying to get "to," as for example the "end product" of a production process, the document that you want, and so on, and this imagery is quite wrong for the web meant to be wandered in.

A sitemap like this is plainly becoming unmanagable for a remote TOC but it does give a better graphic overview of the site. In fact, daVinci allows you to manipulate this graph many ways by hiding things, rotating them, keeping branching levels on a line or not. It thus provides multiple views of the same data structure.

The starburst or chain-reaction cascade graph has the same formal limitations as the trees and boxes, but it is graphically more dynamic and more loosely drawn. I have oriented the starburst below left-to-right to show the parallel with the daVinci flow diagram, though the starburst includes some external sites as well. The starburst is sometimes used, as in the American Heritage Dictionary to represent the relations of languages within a language family. The Java graphics-awt is particularly good at manipulating connected graphs in quasi 3D--a feature which is exploited fully in the new sitemapper Merzscope from Merzcom.*

This is a very powerful program that sketches a draft of your site based on its links (including the external links) and then allows you to edit it by rotating the figure, pulling and shortening the branches, dragging the nodes around, hiding them, zooming in and so on. This allows multiple views, as da Vinci does, but where da Vinci invites you to optimize the graph for non-intersecting lines and good placement of nodes, Merzgraph allows you to move things where you will. It also goes beyond da Vinci's relatively static display to read out information as you touch the various nodes and edges.The links are not headed with arrows, but if you touch them in the master program, they display which file is source and which is target. Because of the maker's great power over the layout, it is possible to use spatial proximity topographically to suggest other kinds of relatedness (always hoping, of course, that the reader will grasp your reason for clustering some things tightly, others more loosely and far off). Here is a snapshot of a Merzgraph of the Phonetics Resources site, this time with external links mapped as well as internal ones.

I used proximity to indicate links to local files (nearer the entrypoint, yes?) and then to cluster related files (there is a bunch of zipped goodie files next to the entry, for example). Note the cross-connecting between nodes (this is a user-selected option). To cross-connect, a file must link as well as be linked. When drawing crosslinks and return loops, Merzscope violates the star-burst metaphor and heads toward a network. Merzmaps are probably not the most efficient tables of contents, but as analytic and interpretive tools, they are very rich. If you have looked at the live version, you will have noticed many more links than in the TOC-oriented Figures so far: Merzmaps seem to me much more useful as a way to study the whole pattern of links on and from a site than as a TOC, especially since they are made automatically (or at least the rough draft is), so I have used them for that purpose. Merzmaps make no graphic distincion between local and external links, and the external nodes can also be expanded, so that a map of my site can include a map of your site. Merzmaps get large in a hurry, of course, as you expand the links on remote sites.

Another web mapper that uses the starburst metaphor is the new Microsoft SiteAnalyzer's Cyberbole display, which indicates when a file is reachable by multiple paths by coloring it green, but does not show its connection to all of its paths at once. (The Cyberbole display does not show multiple paths.) The Cyberbole display, which was actually developed by a small offshoot of Xerox and is included also in Softquad's Hot Metal Pro editor, does allow readers to change position when they expand or contract nodes, but it doesn't allow the map maker to use proximity topographically (though metaphorically). Compare the Cyberbole view of PhonResources

Here we have come into the realm of graphics--this was hand drawn in the well-known Unix program xfig. I have used the same coloring scheme as in the daVinci map and the nested boxes for comparison (though the rank of branching is not wildly relevant here)and the size of the ellipses reflects my sense of the relative importance of the nodes.

Note, by the way, that if we wanted to indicate the remote links also, it could be done with lines, perhaps of a different color or dashed going out to files on the periphery of the diagram. Note too that these could easily be made imagemaps, with each of the boxes/ellipses a hot link to its file. Then they would be just like the remote TOCs, and in fact could be remote TOCs (albeit large ones).

There are a number of other graphing options used in various kinds of networks that I have not seen or attempted for websites. Links can be labelled (and usually are in semantic networks) for the type of relation between the nodes; links between more closely related nodes or frequently traversed ones are sometimes made shorter and sometimes thicker than longer, thinner, more tenuous links.

Overwhelmingly, the imagery of movement in and among sites is that of navigation, and as 3D formats and browsers have developed for game playing, so efforts have been made to increase the perspectives on data structures and processes by attaching hypertext links to polygons and flying through the resulting information landscapes. These take visual proximity and clustering to new heights, but they are rarefied heights, in the sense that we have very little experience with such structures and few conventions about what shape or color or location is meant to signify. At present, many people are building VR browsers, trying to work out the most intuitive set of controls that will enable people to manouver about in 3D space smoothly and precisely. The dogfight mode is not a comfortable one for exploring information, nor is the hiccuping dogfight of VRML on an underpowered (which is to say normal) machine. Those working with VRML tend to build quasi-realistic, banal visual metaphors (a house or room with windows and doors for a home page), a small museum like suite for a Rossetti exhibit, and so on. Abstract three dimensional figures would seem promising, but we have little sense of how to navigate them or where to visit. Here, for example, is a site map of the www.stars.com site (=Web Developer's Virtual Library)that Alan Richmond also drew up in nested boxes:

There are, moreover, other working systems that allow you to fly through data structures. Most of these are propriety--visualization of information being a hot, hot topic--but one is available, at least roughly, in the public domain, namely the HotSauce plugin and freestanding application from Apple's now abandoned X Space project. ^fn The HotSauce plugin responds to a file with an .mcf (meta content file--actually a recognized type) by configuring Netscape or IE into a viewing portal of a space ship for cruising through the data structure. Here are the top few nodes of our sample site:

Notice there are no connecting lines or arrows. HotSauce can operate as a link-follower to construct a map of the whole site, but it prefers to have you put your display together. The color coding is strongly for level and is not customizable--perhaps a good idea to form constant expectations. When you compose your own map, it offers both topics and files to add, so that it is quite easy to construct groupings that may have no actual file or directory that contains or links the groups. Expandable topics are marked with a triangle and multiply linked files are marked with a trident. All file nodes are hot, and the display is clearly intended to function as a TOC as with the VRML objects. HotSauce can also display a more traditional outline.

All of these ways of representing site structure also imply a viewing subject. The standard directories, including the file-and-folder link mappers, are two dimensional and "objective" --the position of the viewing subject does not generate shadows or perspectival effects. The extremely widespread and rapid adoption of drop shadowing on the lettering of names and titles, the use of 3D, even rotating lettering indicates a desire to imply the viewer in the scene. The drop shadows, for example, not only imply letters floating in front of the background plane, they also imply a light source (usually over the viewer's left shoulder).

By the time a site grows to the size inviting mapping, it may well be hard to display, or display intelligently, on one screen. Start displaying file titles, and a map gets cluttered in a hurry. Zooming is a partial solution, in which the viewer has as it were and aerial viewpoint over a shadowless landscape, and can change altitude to optomize global perspective or local detail. These are the strengths of MerzScope and HotSauce, with the latter giving a taste of flying through the data space which is no longer essentially a plane. Panning is sually combined with zooming, so that one can move laterally over the data (or among the data, in HotSauce). The cyberbolic viewer device is more a panner that a zoomer, but it moves the target into prominence (i.e. makes it larger and more central) in the viewing screen while shrinking the peripheral files in to little knots and tangles of lines. To me, the impression is of the data being pasted on the surface of a sphere (a rather small one) so that as one point is brought into focus, the adjacent ones move out to a sloping periphery, and the less adjacent ones slip over the edge of the horizon. This focus-and-periphery imagery is most directly modelled by a new Java navigator(MindMap Navigator) by Stefan Rüttinger that uses starburst imagery and allows you to pan (not zoom) from one node to other nodes you can see, which nodes are dimmed (one link away=dim, two links away=dimmer) in relation to the item in focus. I call this a navigator rather than a mapper, for the script that guides the Java must be done by hand. Here is a snapshot of an MMN view of the Gamelan site

This topic, the reader may be saying to herself, has proved to be more complex than one expected, and indeed it is so for a number of reasons. There are at least three ways to analyze the interrelations of files on a site (file/directory hierarchy, topic hierarchy, link-based webiarchy) and several ways of representing these relations, each with its own visual implications that foreground certain relations and obscures others. It is perhaps no wonder that a certain amount of fudging and blurring has gone on and has engendered some uneasiness and confusion about what these various graphers graph. We have not treated maps with external links, which have a number of purposes. If these links were drawn in for the example site, for example, you could see the points at which the site blended into the surrounding world (and you could see which topics did that the most, and hence which points might likeliest lose the reader to another site.) In any case, the maps would not appear as self contained as they do with external links omitted.