Eidola Notation Gallery

	Notations and Visualizations
	User Interface Philosophy
	User Interfaces of Note
	Existing Visualizations of Programs
	Possible Eidola Notations

Discussion

Eidola home

Nick Weininger argues for the benefits of layering in Eidola:

Displaying a program's semantics fully requires juxtaposing an enormous diversity of types of information. The quantity and complexity of this information are such that it cannot all be displayed at once; nevertheless, the usefulness of a notation largely lies in its ability to display different types and levels of semantic content next to each other, so that the programmer can make connections and comparisons on the fly. It is natural, then, to think that different types of semantic content should be expressed using different layers of graphical elements, which can be added and removed interactively.

Suppose, for example, you're a programmer trying to trace the semantic dependency graph of a particular class Foo. You might start with a fairly "standard" depiction of the class: perhaps just a box marked "Foo" containing a list of member names which can be clicked on to display their types, signatures, function bodies, etc. This box would be one of several boxes within the package in which Foo resides.

Now, you might wish to see what Foo's parents are. This would entail drawing an arrow from the Foo box to the box for each parent. On the other hand, you might also want to look at all of the types of members of Foo, or even all of the types in the signatures of those members: another set of arrows from Foo to some other boxes. And once you follow one of those arrows, maybe you want to look at its parents, or its type dependencies, or... the list goes on. In any moderately complicated class hierarchy, you'd get tangled up in arrows all too quickly. Yet you'd like to be able to see two or three such "basic" dependency sets illustrated at one time, and to flip back and forth between complementary dependency views.

Layers would provide a neat way to do this. One layer holds the basic box displays for Foo and the other classes. Another layer holds the arrows from Foo to its parents. Yet another holds the arrows from Foo to the types of its members. Another still might hold arrows from one of Foo's parents to its parents. The notation should give you a wide variety of options for creating new layers, and let you change the set of displayed layers on the fly.

The danger here is that there are so many different ways to create new layers, a notation might not be able to offer all the relevant options at once (even the options available in a given "mouse context") without resorting to multiple-level pull-down menus, huge option lists, etc. One partial solution is to make the notation adapt to the programmer's action patterns: not only should it store the most recently used layers for quick redisplay, it should learn what types of information the programmer commonly displays in layers, and move those to the top of the options list.