Graphs

At various places throughout the program, it is necessary to display data as a graph. The display of graphs in an aesthetically pleasing manner is well known to be a complex and difficult problem, and many people have carried out work to achieve automation in this field [22,2]. However, as Misue et al have pointed out [10], humans see many other relationships between the nodes in a graph apart from pure connectedness. When a person is left to arrange a graph manually, for their own purposes, they will usually arrange nodes directly underneath each other, in rectangles, and so on, according to gestalt rules [4], as in Figure 3.1. This will be an important factor in my graphical representation of information.

Figure 3.1: The spatial arrangement of objects can give clues as to their relatedness

It is interesting to consider circuit design in relation to software design. Although they are very similar in that they involve breaking down complicated activities into trivial steps, and involve a static representation of a dynamic system, circuits have always been designed graphically, whereas software has always been designed textually. If software design is to become a more graphical process, then presumably circuit design is a useful model to follow. Petre and Green [13] have studied the way experienced electronic engineers use CAD software to design circuits. Their most important result was that experienced engineers made use of ``secondary notation'', a set of informal guidelines as to where objects must be placed in relation to each other to give extra information. Expert engineers read this notation almost unconsciously, often to the point where a novice's diagram, though technically legitimate, will cause great confusion to an expert.

These factors led Misue et al to consider a layout adjustment approach to graph drawing, as opposed to the more traditional layout creation. In their system, a graph was initially created, which the user could then modify in various ways, such as expanding or iconifying a subgraph, or moving nodes around. The graph would then be adjusted to avoid overlaps, while attempting to maintain the overall spatial relationship between the nodes.

My program is designed more as a medium for communication, rather than as an automatic generator of information. I would like to provide an original programmer with the ability to convey information to subsequent programmers with some secondary notation. The actual notation that could be used has not been investigated yet, because systems that allow such spatial notation, to the extent that they exist at all, are virtually unknown in general use. Over the years programmers have invented their own conventions for textual secondary notation [8]--I would expect a similar process to occur for graphical representations. In the meantime, the best strategy for a programming environment is to allow as much flexibility and simplicity as possible. The environment should allow components to be rearranged completely arbitrarily, while maintaining a small set of automatic visual relationships intact.