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.
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.
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.
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.
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.
In the current release of HippoDraw, these views do not update themselves if the model changes. This is probably a bad "feature".
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.
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.
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.
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.
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.
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.
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.
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 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.
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.