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 writes:

I've just finished reading Edward Tufte's The Visual Display of Quantitative Information, which is every bit as excellent as its reviews say. I plan to follow up soon with his other two books, Envisioning Information and Visual Explanations. These latter two supposedly contain advice specifically about computer UI design, so they may have more relevance to the notation question; VDQI is more concerned with statistical charts, graphs, maps, etc. I may change the views expressed below after reading the other two books, so all of this should be well salted before consumption.

However, the central principles of data graphics laid down in VDQI seem to me just as applicable to programming language notation as to statistical charts. Tufte's principles include:

1. Maximize the data-ink ratio. "Every bit of ink on a graphic requires a reason. And nearly always that reason should be that the ink presents new information."
2. Eliminate graphically distracting "chartjunk".
3. Mobilize every graphical element, perhaps several times over, to show the data. However, multifunctioning data should not be so overloaded as to make the graphic into a code that the user must consult a legend to decipher.
4. When possible, shrink displays of parallel data sets down to show them side-by-side as "small multiples" for comparative interpretation.

In short, Tufte's philosophy applies a kind of ruthless minimalism to enable the expression of the maximum amount of data in the least possible space. The desired effect is analogous to the ideal short story beloved of curmudgeonly English professors, in which every word is indispensable to the story.

I think this philosophy carries over well to the display of the semantic data of programs -- and I think minimalism is a crucial design value, in light of the limitations of computer displays, the extreme complexity of large programs, and the speed with which display clutter mounts. One of the cardinal sins of textual source code, it seems to me, is its low "semantic content-to-pixels ratio": quite apart from the failure of source code to exhibit large-scale structural data clearly, most of the characters that make up a source code file are not even directly expressing low-level semantic data. Programming productivity is decreased when programmers must spend time sifting through semantically uninteresting code elements to find the semantically interesting ones.

A good notation, then, should not only strive to call out important semantic data that source code hides; it should refrain from cluttering up the viewing space with any elements that do not express semantic content, be they window decorations, extra arrows, redundant statements, or whatever. Furthermore, it should seek to maximize the semantic content of the shapes in which it presents data-- but not by creating a complicated graphical representation code, i.e. "squares are classes, trapezoids are functions, etc". Instead, it should seek to use graphical juxtaposition as a spur to comparative thinking about program structure.

As an example, it would be enormously useful to have a view of the classes within a package arranged so that the number and complexity of class members is easily visible. One could do this by writing out the signatures of the members in text within a little box representing each class, or by using just the member name to represent each member but scaling it according to the number of arguments, or just having a little bar for each member. The important attributes would be:

• Even in a package with lots of classes, it should be easy to see which ones have complicated interfaces and which ones have simple interfaces; scaling down the text to microscopic proportions should not obscure the relative sizes of the interfaces. (Judicious use of color, variations on shapes, sorting the display order, etc. might help with this).
• It should be easy to zoom in on lower-level semantic elements, e.g. by clicking on a member to display its full argument list.

Such a view would enable a code reviewer to tell at a glance where reviewing effort ought to be focused within a package, a very difficult thing to figure out with traditional source code. The reviewer would then be able to begin reviewing a particular class of class member while keeping an eye on the other classes in the package, which is virtually impossible with traditional source code.