Overview
The paper "Pad++: A Zoomable Graphical Sketchpad For Exploring Alternate Interface Physics" [Bederson et. al.] serves two purposes. First, it provides a high level description of the Pad++ system; both how it behaves and how its implemented. Second, it provides a description of the "information physics" concept and of how zoomable interfaces realize this concept. This work is motivated by the growing size and complexity of information, and by the limitations of the existing user interface metaphors. The primary contribution here is the examination of how spatial representation and semantic structure can interact to allow a user to navigate through space to accomplish a task. One drawback of the paper (although this may be considered elsewhere) is that the nature of the task a user might want to accomplish is not considered.
This paper can be difficult to read, as it tends to jump back and forth between these two themes. Of the two, I believe that understanding the underlying concepts and some of the mechanisms used in Pad++ are more important, and that the implementation details should be used as background knowledge for understanding Jpad. My suggestion for reading the paper are to read the introduction and section 7 (on physics based design strategies) first, then read the rest of the paper. To me, section 7 is the most important one for motivating why one would be interested in this work.
Information physics-based vs. metaphor-based approach
Description
The authors constrast a "traditional" metaphor-based model (specifically the desktop metaphor) with the information physics model. In their opinion the desktop metaphor provides ease of use but has several limitations:
The information physics approach uses a spatial model that is motivated by mechanics, but that adds semantic information. In the author’s description, the "physics-based strategy" encompasses both geometric zooming and semantic zooming. One key insight motivating this work is "adhering to what is possible in the physical world is not only limiting, but also less effective in achieving realism. " In other words, using Newtonian mechanics as a metaphor could be as limiting as using the desktop metaphor.
In our class discussion, Dr. Bederson described interface physics as an alternative to metaphor, in that a set of lower level rules is defined and the user learns the interface by learning the natural consequences of these rules. Most of the class (myself included) read the section on interface physics as being a metaphor based on Newtonian mechanics.
Issues and Questions
The main issue I have with the approach presented in the paper is that it focuses on the representation of data, and doesn’t explicitly consider the human factors issues. In some cases they are implicitly considered, for example in discussing the need to zoom and pan in a smooth, coordinated manner.
Another issue I have with this comparison is that they take their case to an extreme. I would consider the "rubber sheet" model described in the introduction to be a metaphor. Certainly when one uses the term "lens" I am thinking about the lenses I learned about in optics when I read about the corresponding Pad++ concept.
Mechanisms & Implementation
Description
It is important to understand that Pad++ itself is not an application, but a "substrate" from which applications can be built. The paper uses PadDraw as an example application. Pad++ is implemented using C++ and a Tcl scripting interface. This seems like a reasonable approach to me, as I have had positive experience using a Tcl interface to SAND, a spatial database tool developed by Dr. Samet’s group. I do understand the portability motivation for reimplementing the system in Java (the JPad project).
The implementation is described in some detail, but in some places (for example the event model) is hard to understand without actually running the system. The paper describes both mechanisms within the interface (direct manipulation pan & zoom, portals & lenses, the KPL rendering language), and analysis techniques such as space-scale diagrams. I found the space-scale diagrams particularly interesting, because of their capability of looking at multiple levels of scale.
Issues and Questions
The main issue I had regarding implementation is really beyond the scope of the paper: I am interested in how JPad implements these capabilities. The major questions here are
1. Can the Java implementation of a renderer perform well enough with a large set of objects?
2. Which capabilities described here are implemented in JPad?
3. What capabilities should be changed based on research done since the publication of this paper?
An issue that came up in class discussion was understanding how Pad++ evolved from Pad. The paper does not discuss this, but the main evolution was from black and white to color and the addition of smooth animation of the zooming.
Experimentation / Future directions
The section on "Visualization" describes a few systems built with PadDraw. These include an HTML browser using a "fisheye" model and another using the overview/detail model discussed in class, as well as the oval document layout that was demonstrated.
These systems demonstrate the possibilities of ZUIs, but more is needed. There are many tools provided by Pad++ and still more ways they can interact. Experiments are needed to determine which of these tools and interactions are effective from the point of view of the user. One of the key requirements for experimentation (hammered home by Dr. Shneiderman in CMSC 434, for those who took it) is a theoretical model of the human-computer interaction (the other is a practical problem, which is certainly provided by the complexity and scale of information we are trying to navigate). My group in 434 ran an experiment with Pad++, and the lack of attention to such models may be one reason we didn’t come up with any useful results. This paper does not provide any guidance for empirical experiments in HCI.