HippoDraw as Electronic Notebook

HippoDraw as Electronic Notebook

Paul F. Kunz
Stanford Linear Accelerator Center
Stanford University, Stanford, California 94309

Table of Contents


The HippoDraw application started out as simple drawing program that was extended to display histograms, scatter plots, etc. as additional drawable objects. The paradigm was simple, but a number of ways it was used were unexpected. This talk will discuss these ways and the perceived benefits. The HippoDraw application also has some unique features which users have felt improve their feel of the underlying data.

1. Introduction

In the course of working on the Reason project[1], the designers were faced with a decision on how to present multiple histograms in a single window. The dilemma was caused by the fact that the Reason application did not have any commands. Out of this work came the idea to make the window containing the histogram plots a drawing canvas and the plots themselves became graphic objects that could be manipulated on the canvas just like other graphic objects such as circles, rectangles, etc. The idea was implemented and became the basis of the HippoDraw application[2] The implication of this design decision was a lot larger than expected.

One of the aspects of a typical drawing application is that the attributes of graphic object, such as color, line width, etc., can be changed via some panel with GUI-based controls. It was natural to follow this style for changing the attributes of histogram plots as well and a design decision was made to attempt to do so. Again, the impact of this decision was larger than expected.

The HippoDraw application was written with the NeXTSTEP development tools and runs only computers running NeXTSTEP. Although it runs on original NeXT hardware, HP PA-Risc, Sparc, and Intel, not many people have this software installed, so HippoDraw has had limited use. However, it has had sufficient use to learn some lessons from its user interface design, as well as some lessons about its internal software design. These lessons are more important than the application and I hope by presenting some of them here, that authors of other programs will take them as suggestions for their applications.

2. Overview of the Application

Figure 1 shows a screen dump of a running HippoDraw application. In the center is the large window containing the drawing canvas. This is the document window and it is the focus of the user's attention. The size of this window is such that it prints as standard U.S. page (8.5 by 11 inches) or as international A4 size. Note the scroll bar on the left side of the document window. Its size indicates one is viewing one page out of seven and its position indicates we are viewing the second page.

Contributed paper presented at HEPVIS 98, HEP Visualization and Data Analysis Workshop, Stanford Linear Accelerator Center, Stanford, California, January 2-30, 1998
In the upper right of this page is a tools palette containing the common drawing tools. The half height panel in the lower right is called the inspector panel. It is via this panel that one changes the attributes of the graphic objects, except for resizing or moving them on the canvas. The latter attributes are changed by selecting and direct manipulation with the mouse. User input to the controls in the inspector window are applied to the selected graphic.

The upper left of the screen contains the applications man menu where the user will find further controls for opening files, changing fonts, grouping and alignment of graphics, etc. These are controls that either have only a on-off choice, or need to bring up additional panels, such as file dialog or font list, for the user to make a choice.

3. The inspector panel

The inspector panel has eight sub-panels which are selected by the popup button at the top of the panel. Thus, the inspector panel is usually on the screen all the time, but its contents change to allow the user access different controls. We found this design to be better than separate panels for different set of controls because when using applications that have separate panels, we find the screen gets rapidly cluttered with panels and some of them even hiding parts of the document window. One should note from Figure 1, that not only did we decide on only one control panel, but it is also small enough so it is unlikely to sit on top of the document window.

The first seven inspector sub-panels deal with controls on histogram and data. The eighth is purely graphics related. The following is a short description of each sub-panel.

3.1 The data selection inspector

The input data to HippoDraw is an n-tuple either in plain ASCII format or in portable Hippoplotamus[3] format (which is roughly equivalent to a HBOOK n-tuple). Two list boxes display the data that is available. The upper one displays the tittles of the n-tuples that have been read. By clicking on one of them, the lower box displays the names of the columns in that n-tuple.

A new plot is created by first selecting data from the list boxes, selecting the type of plot, i.e. histogram, scatter plot, etc., and then clicking on the "new plot" button. Once the plot is inserted into the canvas, it is possible to change the data that is used by double clicking in the list box., without changing any other attributes of the plot. Thus the application loosely follows the Model-View-Controller (MVC) paradigm that is becoming popular in the Java world. That is, the data is the model, the plot the view, and the inspector sub-panel the controller. One effect of this design is that the user might create one plot, then scan his data by changing the data multiple times.

3.2 The plot options inspector

This sub-panel controls attributes of plots such as error bars or not, bars for histograms versus points, etc. It also controls rotations on 3D plots. In MVC terms, it is pure controller of the view

3.3 The axes options inspector

The main purpose of this sub-panel is to control the axes attributes such as high and low values, bin width, etc. Each of these attributes can be controlled with by either typing desired value in a text field, or dragging a slider. As the sliders are dragged, the plots continuously re-display themselves.

Consider a 1D histogram. What is it, really? The data is one dimensional density distribution which is hard to see. So we project the distribution in two dimensions by binning and that is what we call a histogram. There is some lost of information in this projection and there are an infinite number of possible projections on the same data which differ in the bin width and position of the edges. Which one is best? It depends and takes judgement to pick one that adequately represents the data. By connecting attributes such as bin width to sliders, the HippoDraw application allows the user to see many possible projects in s very short amount of time, like a couple per second, This greatly enhances the users "feel" for the data.

3.4 The plot statistics inspector

This sub-panel is used to insert images into the canvas that summaries the statistics (under, within, over) or the average and standard deviation. In terms of MVC, these are additional views of the model (the data); a numeric view rather than a graphical one.

In the current release of HippoDraw, these views do not update themselves if the model changes. This is probably a bad "feature".

3.5 The cut inspector

The cut inspector sub-panel allows one to apply cuts to plots. When a cut is applied to a plot, a 1D histogram is inserted into the canvas to display the data upon which the cut is based. A shading is added to display the data accepted as seen in Figure 1. Multiple cuts can be applied to one plot and one or more cuts can be applied to multiple plots. In Figure 1, there are three cuts being applied to the upper (larger) scatter plot. The cut inspector is also shown in this screen dump. Note there are two sliders to control the upper and lower limits of the cut. As they are dragged, the target plot continuously updates itself. Which cut limits is best? It depends but this feature allows the user to see many different cut values per second, thus another way of enhancing his feel for the data

In terms of MVC, I must admit that I get a little confused on what is what. The plot with the cuts applied is no longer a view on the original data. Rather it is a view a data set (the model) that was created by the cuts on the original data. The sliders are controllers, but they control not only the created model, but the 1D histogram views displaying the cut values (the shading). Perhaps the MVC paradigm breaks down in this case, or perhaps we have to look at it the right way. At any rate, at the source code level for HippoDraw, it certainly has broken down for lack of a clean design.

3.6 The tuple function inspector

This sub-panel was designed to solve two problems with what has been described so far. One is that plots can only be based on data in the n-tuple. Thus if you had column representing an angle and you wanted to plot cosine of that angle, you can't because there's no place to type in an expression. Second is that multiple cuts on a target plot are and-ed together. If you need a inclusive-or of cuts, so some other complex logical combination, you can't do it from the cut inspector. Although it would have been possible to design are cuts inspector with ability to express different logical combinations, we choose not to because it would probably be complex to write and for the user to understand how to use. Rather, we resolved the need in a way described below.

The tuple inspector allows the user to add a temporary column of data to his n-tuple. When the new function button is pushed, the system's editor is launched on a template C function. The function has two arguments: the row index and a pointer to a C struct which contains all the data for a row. The value returned by the function becomes the data for the corresponding row of the new column. After the user writes his function, saves it, it is compiled and dynamically linked to the running application and the function is called for each row of the n-tuple to create the new column.

In regards to the two problems mentioned above, the user can now use in plots the data in the new column which is a result of any expression based on the original data. This way of resolving the basic need has some side benefits. The authors of HippoDraw don't have to write an expression evaluator (or borrow an existing one) and integrate it into the application. The user doesn't have to learn an expression evaluator; he only needs to learn C if he doesn't already know it. This follows the philosophy: "if you have to learn something, learn something useful." Complex combinations of cuts can not be handled by a tuple function that can return something simple like 0.0 or 1.0, or something more complex.

3.7 The plot function inspector

This inspector allows the user to draw functions on 1D histograms or x-y plots. Standard functions such as linear, gaussian, etc. are built-in to the application. These functions can be used with Minuit fitting. If the user needs to add his own function, he writes a simple class following a prototype class provided. A static member function in the class becomes a Minuit FCN function. Other member functions of the class provide the inspector panel with the number and names of the parameters as well as name for the function. After the user's class is compiled and dynamically loaded into the application, his function appears in the inspector panel alongside the built-in functions.

In this sub-panel, there are sliders to control the function's parameters that the user can use to set the starting parameters for Minuit. When the sliders are used, the user is effective fitting the function by eye; not based on numbers but visually. This gives the user a good feel for what the parameters really do. For example, by varying the normalization parameter of a gaussian one can see the curve go up and down, but by varying the sigma parameter, the curve also goes up and own as it gets wider and narrower.

After a starting point is chosen, the user can push the "start fit" button and Minuit fitting begins. As Minuit is working, updates are made to the function of the plot, so you can "see" Minuit work (Fred James loved this feature when he saw it). If the fit is not converging, the user can hit the "stop" button, go back to his starting point and try different values. Once the fit is complete. The range of the sliders is to one sigma. This allows the user to drag these sliders to "see" what one sigma on a parameter means.

In terms of MVC, a function on the plot is just another view. A fit could be a view of the histogram model, if a fit was done to the contents of the bins, or it could be a view of the data if the fit was done to the data. Yet another view might be the numeric view of the fit parameters, however, this was not implemented.

3.8 The graphics inspector

This inspector control attributes of all graphics, including those is the palette. Included are such items as line with, color, etc. It was not used that often.

4. Document paradigm

Two additional capabilities had to added to HippoDraw from what is described above to make it into a document processor. The first is the ability to save the canvas and state of all objects into a file, that can be opened at a later date. The second is to be able to print the document. Once these features were implemented, there were additional benefits which will be described in the following sections

4.1 Commands and scripting languages

The result of controlling attributes of plots via control in the inspectors, and position and size via direct manipulation via the mouse, is that the HippoDraw application has no command orientated interface. For the authors, there is no command parser to write and for the users no commands to be learned. Both of these are bonuses. However, it leaves some needs unanswered.

In applications that have commands, they can usually be driven by a script written in some scripting language in order to reproduce a set of commands at a later date. Since HippoDraw has no commands, it doesn't have scripting language either. Rather than inventing a command language and corresponding scripting language, the approach taken was to use the document file as the way to reproduce the graphics and plots.

Another use of commands and scripting language is to do something very repetitive, like generate 50 histograms on 50 different channels of something. A scripting language that supports looping and some rudimentary math makes such tasks much easier. The way we would like to have handled this situations, but never implemented it, was to allow users to write a script in the same language that the plot objects are written in. Thus the users would write a function which would be compiled and dynamically linked to the application for execution. Doing it this way would mean that the HippoDraw authors would still be able to avoid inventing and supporting a scripting language, while the users would only need to learn the language of HippoDraw itself. This language is Objective-C which is a C based language with a quite easy to learn object oriented extension. The users would then have same object oriented interface available to them as the code behind all the controls in the inspectors. The authors of HippoDraw, of course, would have to document this interface.

4.2 A document as a template

One of the uses of commands and scripting languages is to generate the same set of plots, cuts, etc. on n-tuples of the same format but corresponding to different data sets. The way this need is resolved in HippoDraw was to use a saved document as a template for many data sets. When the document is saved, by default only a reference to the n-tuple file is saved, not the data itself. Thus, if the document is opened at later date and the contents of the n-tuple has changed, then the contents of all the plots will change automatically. Equally well, a user can open one or more additional n-tuples of the same format, select all the plots, then replace the n-tuple used by them via the data inspector.

One problem with storing a reference to the n-tuple file is that one might open a document containing a reference to a file which no longer exists. Or the document file might be moved to another site and the n-tuple file can not be accessed. To accomodate this situation, histograms saved their bin contents as well as the other attributes. Thus at least the histograms display themselves as they were before the n-tuple file was lost.

4.3 A document as a logbook

Since their first physics laboratory course, physicists keep a log book that records the steps taken to reach a result. With a typical histogram viewing application, one needs to print what one sees on the screen and paste the plots into the logbook at pertinent points in the analysis chain. Any notes, or numeric results may have to be hand written in the logbook.

With HippoDraw, users used the document file as their logbook. That is, when they were satisfied with some plot along the analysis chain, but needed to proceed further, they leave that plot on the canvas and create a new plot for the next step. The result is the sequence of important plots and their cuts, fits, etc., are recorded in the document. Users could also use items in the graphics palette, such as the text object, to annotate the document. So as users work on their data with HippoDraw, they are continuously writing their logbook.

4.4 HippoDraw as a drawing tool

Since HippoDraw is a rudimentary drawing application, some users used it as one. The difference between HippoDraw and pure drawing tool is that the plots were live.

Some users used HippoDraw to produce transparencies for presentations on their analysis. Any last minute changes in the n-tuple data or other parts of the analysis was immediately updated in the transparencies. One user used HippoDraw to produce transparencies for all this talks, even if they did not contain any plots (a bit extreme in my opinion).

HippoDraw had the ability to generate from selected graphic(s), an encapsulated Postscript or TIFF file. Some users used this feature to create the graphics for their thesis and papers.

5. Future prospects

The HippoDraw application grew slowly, rather than being carefully designed from the beginning. On the one hand, it was an experiment to see if one could build an n-tuple visualization tool that was purely GUI-based. At this it was reasonably successful. It also demonstrated that some GUI-based controls, such as sliders to control histogram bin size, presented new ways of understanding the underlying data. GUI-based controls also made possible an ease of use which one CERN user summed up by saying: "HippoDraw is so easy to use, that even a 50-year old CERN physicists can use it"[4]. Also, the document-centric nature of the application lead to uses that were unforeseen. Most users took the document created by the application as a form of electronic notebook. Others used the document as a template to study different data sets.

But HippoDraw suffers from a number of aspects of its design. For one thing, it did not follow MVC paradigm strictly enough. This leads not only to some maintenance problems, but also, the adding new views and/or new controls is not as easy as it could have been. Even more interesting, would be the possibility of adding new models as opposed to being strictly n-tuple based. Thus, one could consider HippoDraw as a prototype and speculate what a future application based in this prototype might be able to do. Finally, HippoDraw was developed in an environment that did not succeed in the market place, thus although the number of its users was not insignificant, it never reached a broad audience that could have contributed more suggestions, constructive criticisms, and maybe even some code.

The document-centric application that one might build in the future, would follow the MVC pattern. The application itself would be very simple. An item on its view palette can be selected, cloned and placed on the drawing canvas. It can also be asked to provided an inspector class which the application puts into the inspector window. The application only knows the abstract view and inspector interfaces, not any details implemented by concrete classes. It is thus remains simple and the application extendible.

Examples of such applications can be easily found, although they are usually specialized towards producing something that is not a document. NeXTSTEP's InterfaceBuilder application is and good example. However, it produces a GUI for an application. Other C++ or Java GUI-builder applications are similar, although not as well done. The Java based BeanBox is another example. Although it also does not produce a document, it does have views (called beans) with their corresponding inspectors (called property editors) and the Java Beans environment strongly encourages the MVC pattern.

The application I visualize for the future could import, various kinds of data with a set of model classes. Thus there needs to be a list of models available so the user can select one to instantiate. Event data and n-tuple data models are two examples. The model class will also supply a controller which would be presented in the inspector window. Amongst other controller tasks, it would the read in the data by opening a file or making a network connection. In either case, the inspector would present to the user a file dialog panel or other means to identify the data set and the application remains simple since it has no knowledge of it.

With HippoDraw, we've seen quite a number of views one would have with n-tuple model data. For event data model, one would also have a number of different views. For example the standard x-y, x-z, y-z views of the tracks in the detector geometry. Each view could separately be placed and sized on the canvas. The 3-d view that can be rotated is yet another and it would have its separate controller. Yet another 3-d event view might be one in which each track is represented as a vector along the track's initial direction whose length is proportional to momentum. When such a 3-d view is rotated, one can easily see aspects of the event that aren't apparent in conventional views. Yet other event views that might be made available via the palette might those more exotic, yet useful, displays proposed by Hans Drevermann[5] For the tracks in an event, one might want to insert a tabular (or spreadsheet-like) view onto the canvas. The underlying model supporting the tabular view is an n-tuple, and thus any of the views capable of using the n-tuple model could be used on this track table.

Thus, a document-centric application as described above, could be uniform framework for doing many different kinds of analysis. One benefit of this is that users will have less different applications that they would need to learn. Another benefit, that might be even more important, is the application could be a framework where people could easily try out new ideas in visualization. For example, suppose someone has a new idea on how to represent multiple dimensional n-tuple data. In this framework, he would have to write his view class, of course. Separately, he would write a class for the controls of his view. Both would follow the interfaces defined in the application. Finally, he would need to get his view onto the palette via its name and/or small icon. That would be basically it. If it would be that easy to try out a new idea, then maybe people will. If much more work was involved, as would be the case with a large monolithic application, then people might not for a variety of reasons.

6. Conclusions

HippoDraw has demonstrated interesting features which seems to be unique to this application. It is completely GUI based, thus has no commands or corresponding scripting language. Except for the case of repetitive creation of plots, the lack of commands or script does not appear to be a limitation. Rather, the GUI based control environment allows one to visualize and understand the data much more quickly and with far greater ease of use. The document-centric paradigm also proved to be very useful in ways that were not foreseen.

I would encourage authors of other visualization applications to borrow ideas from HippoDraw. I think it would be good service to our community, and others, to port something like HippoDraw from its current environment, with its very limited number of users, to one that is commonly found on desktops.


The users of HippoDraw have contributed many idea via constructive criticisms and suggestions. Amongst the most vocal were Bill Atwood and Tom Pavel. The author was aided in development of the application by Mike Gravina, Paul Rensing, and others.


W.B. Atwood, Richard Blankenbecler, Paul F. Kunz, Benoit Mours, A. Weir, G. Word, The Reason Project, Conf. on Computing in High Energy Physics, 8th, Santa Fe,N.Mex., Apr 9-13, 1990, AIP.
Michael F. Gravina, Paul F. Kunz, T. Pavel, P. Rensing Proc. Workshop on Software Engineering, Artificial Intelligence and Expert Systems for High-Energy and Nuclear Physics, La Londe-Les-Maures, France, Jan 13-18, 1992. World Scientific.
Michael F. Gravina, Paul F. Kunz, Tomas J. Pavel, Paul E. Rensing. Contributed to 10th International Conference on Computing in High Energy Physics (CHEP 92), Annecy, France, 21-25 Sept. 1992.
person forgotten, private communication.
H. Drevermann, D. Kuhn, B.S. Nilsson, CERN-ECP-95-25, Oct 1995