Additional Directions



next up previous
Next: Conclusion Up: Visualizing the Structure of Previous: Implementation

Additional Directions

The structure of the Web is just one of many potential applications of visualizing directed graphs with cycles. The file format expected by the webviz program can easily be generated by programs other than a Webspider. We have implemented a straightforward Unix filesystem explorer using find and perl. Figure 9 shows the directories on the SFB 288 filesystem and the symbolic links between them. The complex subtree at the lower left is /usr, the node with the most children at the upper left is /u (the index of all home directories), and the many symbolic links at the top connect NFS-mounted disks local to individual machines to the main filesystem. We would like to try visualizing other kind of information, such as object class hierarchies.

 

Figure 9: Filesystem visualization

WebOOGL [330KB] VRML [770KB] MPEG [380KB]

The system is currently limited by rendering speed. Level of detail control will be crucial to extending its reach.

The current Webviz system is batch-oriented: the Webspider explores a Weblet to a specified depth and then the graphical representation is constructed and written out into a 3D data file. The file is then loaded into Geomview through the WebOOGL system. The current WebOOGL interface controls the click action, toggling between showing information about the node and following its link. A nice extension would be a user interface for interactive control of the Weblet exploration, where possible click actions would be collapsing or exploring nodes, selecting which backlinks to draw or hide, etc.

There are a number of possible directions for the layout. We now always avoid overlapping nodes by erring on the side of over-allocating space for the children of a node. Not only can this obscure the big picture, but also the current scheme runs into floating-point precision difficulties after several generations. (Of course, without level of detail culling we are often render-bound after three or four generations.) Distributing the child nodes on the surface of spheres instead of cones would use space more efficiently. An interesting approach would be to use the currently computed layout as the starting point for a dynamical system where the edges act as repulsive springs. The system could evolve until it converged to a solution which fits (no overlap) and fits well (each node occupies just as much space as it needs). Because of the self-similar nature of trees, this dynamical system would probably need to be applied in a hierarchical way similar to multi-grid techniques. Another interesting tactic would be to draw the backlinks as splines instead of straight lines. While splines in Euclidean space have been extensively investigated, hyperbolic splines have received much less attention.

Much more could be done to graphically represent the contents of the node. Color coding is now used to show link directionality and to crudely show the generation in the tree. For example, color coding and edge thickness could represent attributes such as document size, number of accesses, modification times, and so on. All nodes are now HTML documents and are just drawn as tetrahedra, but if the Web spider were improved to gather information for all recognized MIME types the node shape could represent the document content type.



next up previous
Next: Conclusion Up: Visualizing the Structure of Previous: Implementation



Tamara Munzner
Tue Nov 21 23:43:05 CST 1995