The rules are put into a computable form, and an architecture for applying them automatically is outlined.
They begin by asking "What Makes a Diagram Look Good" (p. 546). They factor the answer to this question into "visual complexity, regularity, symmetry, consistency, modularity, sizes, shapes, separation, and traditional ways of drawing [all of which] affect our judgment of whether a diagram is good" (p. 546)
It is interesting to note that most of the rules mentioned in the
paper could easily be applied to custom-designed data structure
diagrams. Think about the validity of the rules when applied to, say,
a picture of a clock used to display the state of a "time"
record. This suggests that their system of rules is widely applicable
and useful in a broad sense with respect to the goal of evaluating
& designing data structure diagrams (not just to automatically
constructed & generic diagrams).
Pointers and recursive data structures create a special problem
because of the need to automatically choose where to layout the
objects in a data structure of unknown size. Incense's solution was to
use a special type of artist called a Layout for structures
containing pointers. Layouts consist of Layout Fields -- one
for each pointer and each referent in a Layout. Such structures are
drawn recursively by calling the appropriate Artist or Layout for each
field and referant of a pointer or record.
Incense uses splines to draw pointers, with default destination points
at the center of the left sides of an Artist. For records and arrays,
the destination is the center of the left side of the first field. In
terms of the rules presented in the last paper, this is not optimal:
their method for choosing spline control points does not minimize turn
angles. Since Incense does not choose how to display data structures
based on aesthetic rules, their choice for pointer arrival places may
not always be optimal. Note that the configurability of their system
makes it a simple matter to incorporate more of these rules. However,
it's not clear that the user has much control over Incense's choice to
use splines for pointers.
Myers
Purpose
This paper describes the Incense data structure display system
(written for the Pascal-like language Mesa. One strong
motivation for making a data structure display system is its
helpfulness in debugging. This also adds some constraints to the
system: it must be quick and should be able to automatically generate
diagrams, since it will be used in a very interactive setting where
the user may wish to quickly view many pieces of information without
having to specify a format each time. Incense is designed to do well
in a debugging context, but also has facilities for customizing
display to create more sophisticated displays (useful in an
illustrative setting). The Incense developers do not appear to have
followed as strict a set of rules as D & M, but they do state that
"A guiding principle of Incense is to automatically create displays
that would be similar to those the programmer might have drawn on
paper" (p. 116).
Description
Each data structure which is displayed in Incense has an associated
Artist which contains the actual code for displaying, erasing,
or modifying pictures of the data. An Artist contains multiple
Formats in which the data is displayed. Formats are radically
different ways of representing data (eg a clock format and a record
format might both be associated with a time record). A data
structure might be displayed in more than one Format at once. These
are generally selected by the user. Each Format has multiple
Subformats which are chosen automatically based on contextual
information such as the number of pixels in which a picture has to fit
(a boolean test associated with each Subformat helps decide which
should be called). Artists are provided for every Mesa datatype, but
users can create new Artists and Formats if they wish, either by
writing Mesa programs or simply controlling variables such as the
sizes of field elements in order to emphasize or de-emphasize
them. Recursive data structures and records have an Artist associated
with each field/object. Evaluation & Open Problems
Incense appears to be a very useful tool for data-structure
display. It is certainly useful in illustration design and code
documentation, since the user can customize illustrations, but I
question it's usefulness in a more real-time interactive context. The
final paragraph of the Incense paper claims that "The displays from
Incense-like systems help the programmer monitor and understand the
execution of complex programs" and that "debugging will probably be
more enjoyable when using pictures rather than long strings of
characters" (p. 124). I would like to see some empirical support for
these claims. While their system is customizable, one would hope that
the automatically generated diagrams are sufficient -- but that is
hard to accomplish, and their paper does not show that they have done
so.