Zoomable Graphical Sketchpad
Pad++ is a general-purpose substrate for creating and interacting with structured information based on a zoomable interface. It adds scale as a first class parameter to all items, as well as various mechanisms for navigating through a multiscale space. It has several efficiency mechanisms which help maintain interactive frame-rates with large and complicated graphical scenes.
While Pad++ is not an application itself, it directly supports creation and manipulation of multiscale graphical objects, and navigation through spaces of these objects. It is implemented as a widget in Tcl/Tk [25] (described in a later section) which provides an interpreted scripting language for creating zoomable applications. The standard objects that Pad++ supports are colored text, graphics, images, portals, and hypertext markup language (HTML). Standard input widgets (buttons, sliders, etc.) are supplied as extensions.
One focus in the current implementation has been to provide smooth zooming within a very large graphical datasets. The nature of the Pad++ interface requires consistent high frame-rate interactions, even as the dataspace becomes large and the scene gets complicated. In many applications, speed is important, but not critical to functionality. In Pad++, however, the interface paradigm is inherently interactive. One important searching strategy is to visually explore the dataspace while zooming through it, so it is essential that interactive frame rates be maintained.
A second focus has been to design Pad++ to make it relatively easy for third parties to build applications using it. To that end, we have made a clear division between what we call the "substrate", and applications. The substrate, written in C++, is part of every release and has a well-defined API. It has been written with care to ensure efficiency and generality. It is connected to a scripting language (currently Tcl, but we are exploring alternatives) that provides a fairly high-level interface to the complex graphics and interactions available. While the scripting language runs quite slowly, it is used as a kind of glue language for creating interfaces and putting them together. The actual interaction and rendering is performed by the C++ substrate. This approach allows people to develop applications for Pad++ while avoiding the complexities inherent in this type of system. (See the Implementation section for more information on this.)
PadDraw is a sample drawing application built on top of Pad++. It supports interactive drawing and manipulation of objects as well as loading of predefined or programmatically created objects. This application is written entirely in Tcl (the scripting language), and was used to produce all the figures depicted in this paper. The tools, such as navigation aids, hyperlinks, and the outline browser, that we discuss later, are part of this application.
The basic user interface for navigating in PadDraw uses a three button mouse. The left button is mode dependent and lets users select and move objects, draw graphical objects, follow hyperlinks, etc. The middle button zooms in and the right button zooms out. Zooming is always centered on the cursor, so moving the mouse while zooming lets the user dynamically control which point they are zooming around.
PadDraw has a primitive Graphical User Interface (GUI) builder that is in progress. Among other things, it allows the creation of active objects. Active objects can animate the view to other locations (a kind of hyperlink), or move other objects around on the surface.
Easily finding information on the Pad++ surface is obviously very important since intuitive navigation through large dataspaces is one of its primary motivations. Pad++ supports visual searching with direct manipulation panning and zooming in addition to traditional mechanisms, such as content-based search.
Some applications animate the view to a certain piece of data. These animations interpolate in pan and zoom to bring the view to the specified location. If the end point is further than one screen width away from the starting point, the animation zooms out to a point midway between the starting and ending points, far enough out so that both points are visible. The animation then smoothly zooms in to the destination. This gives both a sense of context to the viewer as well as speeding up the animation since most of the panning is performed when zoomed out which covers much more ground than panning while zoomed in. See the section on Space-Scale Diagrams for more detail on the surprisingly complex topic of multiscale navigation.
Content-based search mechanisms support search for text and object names. Entering text in a search menu results in a list of all of the objects that contain that text. Clicking on a element of this list produces an automatic animation to that object. The search also highlights objects on the data surface that match the search specification with special markers (currently a bright yellow outline) that remain visible no matter how far you zoom out. Even though the object may be so small as to be invisible, its marker will still be visible. This is a simple example of task-based semantic zooming. See Figure 2 for a depiction of the content-based search mechanism.
Figure2: The content-based search window lets users search for text and names, and then animate to any of those objects by clicking on the search entry.
We have also implemented visual bookmarks as another navigational aid. Users can remember places they've been, and maintain miniature views onto those places. Moving the mouse over one of these bookmark views places a marker in the main view to identify where it will take you (although the marker may be off to the side and hence not visible). Clicking on a view animates the main view to that place (Figure 3).
Figure 3: Visual book marks let users remember interesting places they've been by showing miniature views of those places. Clicking on one of these miniature views animates the main view to the remembered location.
Portals are special items that provide views onto other areas of the Pad++ surface, or even other surfaces. Each portal passes interaction events that occur within it to the place it is looking. Thus, you can pan and zoom within a portal. In fact, you can perform any kind of interaction through a portal. Portals can filter input events, providing a mechanism for changing behavior of objects when viewed through a portal. Portals can also change the way objects are presented. When used in this fashion, we call them lenses (see below).
Portals can be used to replicate information efficiently, and also provide a method to bring physically separate data near each other. Figure 1 was created using several portals, each looking at approximately the same place at different magnifications.
Portals can also be used to create indices. For example, creating a portal that looks onto a hyperlink allows the hyperlink to be followed by clicking on it within the portal, changing the main view. This however, may move the hyperlink off the screen. We can solve this by making the portal (or any other object for that matter) sticky, which is a method of keeping the portal from moving around as the user pans and zooms. Making an object sticky effectively lifts it off the Pad++ surface and sticks it to the monitor glass. Thus, clicking on a hyperlink through a sticky portal brings you to the link destination, but the portal index isn't lost and can continue to be used.
Designing user interfaces is typically done at a low level, focusing on user interface components, rather than on the task at hand. If the task is to enter a number, we should be able to place a generic number entry mechanism in the interface. However, typically, once the specific number entry widget, such as a slider or dial, is decided on, it is fixed in the interface.
We can use lenses to design interfaces at the level of specific tasks. For example, we've designed a pair of number entry lenses for Pad++ that can change a generic number entry mechanism into a slider or dial, as the user prefers. By default the generic number entry mechanism allows entering a number by typing. However, dragging the slider lens over it changes the representation of the number from text to a slider, and now the mouse can be used to change the number. Another lens shows the data as a dial and lets you modify that with a mouse as well.
More generally, lenses are objects that alter appearance and behavior of components seen through them. They can be dragged around the Pad++ surface examining existing data. For example, data might normally be depicted by columns of numbers. However, looking at the same data through a lens could show that data as a scatter plot, or a bar chart (see Figure 4).
Lenses such as these support multiple representations so that information can be displayed in ways most effective for the task at hand. They make the notion of multiple representations of the same underlying data more intuitive and can be used to show linkages between the representations. For example, if the slider lens only partially covers the text number entry widget, then modifying the underlying number with either mechanism (text or mouse), modifies both. So typing in the text entry moves the slider, and vice versa.
Figure 4: These lenses show textual data as scatter plots and bar charts.
Once we make zooming a standard part of the interface, many parts of the interface need to be reevaluated. For example, we can use semantic zooming to change the way things look depending on their size. As we mentioned, zooming provides a natural mechanism for representing abstractions of objects. It is natural to see extra details of an object when zoomed in and viewing it up close. When zoomed out, instead of simply seeing a scaled down version of the object, it is potentially more effective to see a different representation of it.
For example, we implemented a digital clock that at normal size shows the hours and minutes. When zooming in, instead of making the text very large, it shows the seconds, and then eventually the date as well. Similarly, zooming out shows just the hour. An analog clock (implemented as a lens that can be positioned over a digital clock) is similar -- it doesn't show the second hand or the minute markings when zoomed out.
Semantic zooming can take an even more active role in the interface. It can be used as a primary mechanism for retrieving data. We have built prototype tools for accessing system usage including information about the print queue, the system load, and the users on the machine. They are depicted as small objects with labels. Zooming into each of them starts a process which gathers the appropriate information, and shows it in the now larger object. Zooming out makes the information disappear and the data-gathering process inactive.
Copyright Computer Science Department, The University of New Mexico