There are four key issues that the papers discuss with respect to data structure visualization.
Both address speed (or the lack thereof), but not how it affects usage of the overall package.
The example presented at the beginning of the VIPS paper, which demonstrates the use of the tool when debugging a simple tree structure, heavily depends on shape recognition. The ability to quickly detect when a structure is shaped incorrectly is very valuable to a programmer for many reasons. First it allows them to detect that a problem exists at all. By looking at addresses alone, it would be impossible to tell that the tree was being built incorrectly. It also helps to narrow down the scope of where the bug might be occurring: is it in the tree building code or in the tree traversal code? Being able to visually detect errors takes advantage of the programmer's strong perceptual abilities, which are generally ignored in most text-based debugging environments.
The organization of the VIPS system uses multiple windows. The "main" window is the "Whole List View" which displays the overall framework of the data structure being observed. It hides details such as doubly-linked lists and cyclic structures so the programmer can concentrate on the overriding structure. The Whole List View also provides the selective display of any region of the data structure in order to reduce its complexity and allow the programmer to concentrate on the portion that is relevant.
While hiding the details might be useful in some situations, in others it can cause more problems that it might solve. Consider a fully connected graph of 5 nodes. Instead of nicely displaying the structure as a ring with all nodes connected, the overview would either be a tree with three levels, or a single linked list, depending on how it did traversal. The representation has nothing to do with the real structure of the data. It can be even more confusing to the programmer when data they are expecting to be structured one way looks very different on the screen (p 49).
VIPS also provides a more close-up view to see the true structure of the data (with all cycles and links). To achieve better speed and reduce complexity, this view is limited to only viewing 10 nodes at a time.
As shown on p 49, pointers are always drawn as straight lines, even when they must pass through another node (or even itself) to reach the destination. This adds clutter, confuses the programmer, and adds complexity to an already complex display. The 10 node limit reduces the problem of how to squeeze large amounts of information into a small view by placing an upper bound on it. Now, there is no shrinking of structures to squeeze them in. While this is simple (maybe a cop-out on the programmer's side), is it a reasonable approach? The GDBX paper does a much better job with this, but possibly at the expense of speed.
The authors claim that multiple views are important, but I claim that integration of the views is just as, if not even more, important. VIPS integrates the views in several ways. First, it shows the current selection in all the views. This reduces the chance the user will get lost among all the data and provides the user their bearings. Furthermore, VIPS displays the outline of the area displayed in greater detail in a close-up view. In general, if the views are not well integrated, the user will get lost trying to find their data among several unconnected views.
This can have its downside as well. The highlighting of nodes can be confusing if the two views do not match in their display of the structure, since the user expects that they will (see p 49). Also, a small outline will get lost if there are many nodes in the Whole-List view. The outline might even clutter up the picture so that nodes are difficult to see. Here, color (or light patterns) could be used to "gray out" the nodes that are not being viewed, emphasizing which areas of the structure are displayed in more detail.
The VIPS paper talks very little about change detection, only briefly mentioning that it highlights elements that have changed in reverse video. For one of their main criteria, they sure don't spend much effort discussing it. GDBX was skimpy on this topic as well, burying the "flash" feature deep in the command documentation.
Apparantly, more research needs to be done in the realm of visualizing changes to data structures. This quarter, my project in the Grad Compiler's class is along the lines of visualizing differences between lists of instructions, registers, and symbol information generated at different stages of gcc's optimization phase. Maybe some of this can be applied to data structure vis in general.
GDBX encompassed the points made in the VIPS paper, and even added a few that VIPS did not even deal with. Mostly these were modifying the elements on the screen and not limiting the display areas to a fixed number of nodes.
Where GDBX really differs in its approach to modifying the presentation of data structures. While it has a simple algorithm for the initial placement, it gives the final control to the user by allowing them to drag structures around and place them anywhere on the screen. Links to that structure are the updated to reflect its new location. Furthermore, it allows users to link data structures on the fly by moving and re-directing pointers.
While this is all nice on paper, how well does it work? The exact destination address of a pointer to a structure is ambiguous because one cannot tell if its pointing to the structure or to an element. Also, once the arrow has been drawn, how well does it update and still point at the same place? How well does it handle the node being moved such that the new arrow much cross a different node? The simple placement scheme now gets very complicated. Moreover, is it really useful to be able to move nodes around? It adds complexity to the interface and the display, while not really providing anything concrete. I can't think of how I would use it.
GDBX stresses the idea of the box and arrow metaphor, which dominates data structure visualization tools even today. Is this metaphor adequate? Can we do better, and still retain automation? If I have a linked list that represents a stack, I don't want the data structure displayed as a linked list. I couldn't care less how it was implemented, since it is probably some ADT from a library like RogueWave. I want to be able to look at it and see it as a stack. Simply put I want to recognize more than just structure, but also meaning and semantics. Is this possible?
Written for CS7390 - Software Visualization - Spring 1996
Mike Pinkerton -- College Of Computing