"What to draw? When to draw? An essay on parallel program visualization." -- Bart P. Miller

• The two basic problems in visualization are:
  • To model the system
    Visualization of parallel programs is difficult because we cannot appeal to a physical model. Most of the constructs in Computer Science are artificial.
  • To illustrate this model
    Given a model, one has to design a picture to represent it. If we can get past the first stage and find an intuitive model with wide appeal, then we may be able to share techniques with other fields.
• Below, we discuss each criteria for good Visualization briefly.
  • Vizualizations should guide, not rationalize
    "Guide" means that the visulaization leads one to discover things that one did not already know. "Rationalize" implies illustration of already known things.
  • Should be appropriate to the programming model (control view vs. data view)
    For example, if a programmer uses procedures, explicit process creation and explicit synchronization, then the displays can be in terms of these operations.
  • Scalability is crucial
    Any visualization tool that is based on processes, threads, or procedures will have to deal with hundreds, even thousands, of objects. A display might deal with scale by inherently being able to organize large amounts of data. Alternatively, a display might deal with scale through alternate views.
  • Color should inform, not entertain
    Color should either increase the information density, accent imortant cases, or aid in specification. Color is appealing, but it should used only when it adds information.
  • Should be interactive
    A visualization that tries to give all the information in one view can be overwhelming. The visualization should help you decide what information you need to see next.
  • Should provide meaningful labels
    A visualization should provide a means for identifying the program or system objects that are being described (for example, by explicitly labeling them in the display).
  • Default Vizualizations should provide useful information
    A visualization tool should provide a set of useful default views. These views should, in most cases, be sufficient for programmers to find their problems.
  • Avoid the "watchmaker's fascination"
    It is hard to say the time by looking at the internal gears and levers in the inside of a watch, however fascinating they may appear. Developers must avoid the temptation to show all the low-level details in a visualization.
  • Vizualization controls must be simple
    It is important that the visualization has fewer buttons and guages than an F-16 fighter ! A tool will often have dozens of options that can be set, but only relatively few combinations of these options may be sensible. The controls can be much simpler with fewer choices.
• To evaluate our visualizations: tests on real programs and have other people use it. It is not sufficient to try the tool on a familiar program and see if it gives the expected results. The visualizations must be tested on real programs. The tools must also be tested on different users.