Docuverse represents a large document space. Each object in the space is rendered as a small dot and the color of the dot depicts the state of one of the object's attributes. Shneiderman's [16,8] Treemaps provide similar results by rendering files and directories as bars. In the Docuverse, files (or documents) are shown as colored arc segments and directories (or containers) as enclosed pie segments. At the current time, the Docuverse allows the user to recursively display up to six levels of the document tree structure showing the size, type, age, number of links, or usage of each object. Figure 1 shows a 4-level directory hierarchy containing 3502 files in 164 directories showing the age of each files. Theoretically, using an arc size of one pixel, one could display 1,000,000 documents on a 1000x1000 pixel display. In reality, we think it would be possible to display up to about 10,000 documents in a Docuverse space, and practical to display 3,000 or so documents comfortably.
In early renderings, we used saturation as the variable for the depicted
objects but found it to be unacceptable for distinguishing among objects.
The current version uses hue ranging from blue to green to yellow to orange
to red for the depicted dimension. Thus, small files are blue and large
files are red; new files are blue and old files are red
; etc. How to handle
the arrangement of directories or containers has proven to be problematic.
At the current time, we have settled on a circular representation. Each
directory or container has a minimum radial size. The starting directory or
container is
depicted as a full circle. The attribute depicted is noted
in the center of the circle. Around this circle, the
subdirectories are arrayed as pie segments. The size of the arc subtended
by each subdirectory
pie segment is determined by the number of subdirectories it contains as a
percentage of the total number of subdirectories at the next level.
Thus, if the current root contains three subdirectories A, B, and C and
the number of subdirectories in A, B, and C is 5, 10, 15, respectively, then
pie segment A will subtend 5/30, or 1/6 of the circle, B will subtend a third of the
circle, and C will subtend half. In practice, this has generally provided
a reasonable distribution of space at lower levels. Each segment is guaranteed a minimal
radial length. If the surface area of the pie segment is insufficient
to display the files it contains, the necessary radial length of a directory or
container space is determined by calculating the surface area required to
display the number of files in the subdirectory. Given a known subtended
arc, the radial size required may be quickly calculated.
The Docuverse map is click sensitive, so that left clicking in any area will indicate the directory or container. Double left clicking will regenerate the plot with the indicated directory at the center. Right clicking will switch to the Webview with the indicated directory at the root.
Figure 1: A Docuverse View Showing Age
Attributes of the objects depicted are accessible from a database or the file system. The time required for the system to navigate the database or document space and generate the data to produce the views can be several seconds. As file-specific information is extracted to develop a view, the time required to generate a view can be tens of seconds. For this reason, Docuverse views are saved as vectors of the necessary information and regenerated from the vectors. For complex displays, this provides one to two orders of magnitude increase in performance. Given the use of Docuverse to identify broad trends, we imagine that it will be acceptable to generate the vector maps during downtime and to have the standard mode of operation for Docuverse be one of using the vector maps rather than doing the query from scratch. Furthermore, we anticipate that views can be saved as bitmaps that can be rendered by the system very rapidly making it possible to produce animations of change over time for a given area and attribute. The vector maps will continue to contain the coordinate information needed to identify the areas or files on the map, but will not be used to generate the maps.
Docuverse provides a mechanism for seeing big trends. Consider a Docuverse plot of the hits on various pages served by a given html server, or a plot of the timing of comments made on a large standard. For example, Docuverse can shows in one image the 2000 comments made on one of the IEEE Posix standard (see Figure 2). From this view, it is possible to determine the distribution of comments across the documents chapters. It is also possible to see the timing of the comments.
Figure 2: Docuverse View Showing the Number and Type of Comments on a Posix Standard
Experimental tests will determine what characteristics, e.g., size, age, or type, number of links, etc. are of most interest to users. For the CASCADE project, we anticipate keeping a number of attributes in the controlling DBMS. Thus, in a collaborative effort, users could ask to see the amount of time files were open, the number of accesses by members of the group, the number of comments or objections recorded, the number of edits, etc.
Users might also wish to use change patterns in maps as a focus mechanism. Thus, sequences of maps taken over time might be played like a movie to show changes in activity across broad areas of the Docuverse. For web servers, deltas of all sorts might be of interest. Changes in the number of accesses to document or the length of time spent on a document, or the number of links to and from various documents. Finally, some users have asked for a lens feature in Docuverse that would allow the identification of individual files. The vector maps make such identification easy, and future versions will explore the utility of this feature.
The Docuverse shows selected characteristics of the objects in a broad expanse of the document space. For more detailed views, the user would shift to the Webview browser.