Mick McQuaid

Prototyping is one of the three main activities in the iterative design process, pictured above. Most of you have experience in this process and have some opinion of the value of cranking through the cycle rapidly so that each of the three stages maximally benefit from the other two. In the workplace, you may find yourself completing this cycle on a weekly basis, indicating that you spend very little time in each stage. Prototyping and Evaluation are more dependent on external people (related software developers and user test participants), so these are the stages most at risk for delay. Because of this, a general prototyping issue is the rapidity with which you can implement the choices you’ve made in the design stage.

General prototyping concerns apply to information visualization, but let’s look at what’s particular to InfoViz, where information representation looms as a central issue. You can certainly program any information representation in Java, but a toolkit like prefuse can supply these for you to try out with very little time investment. Above is a figure from Heer (2005), showing a number of information representations available to prefuse users. Imagine that you want to visualize information where you’ve already decided that hierarchical relationships need to be emphasized. The most obvious representations in the above figure are the hyperbolic tree and the treemap, but for some hierarchies, some of the others might be promising candidates. The problem is that there is high risk associated with using network layouts to display trees. A risk averse prototyper may not be able to afford to invest much time in looking at network layouts for trees. A toolkit like prefuse can enable you to get the most out of the prototyping stage, especially early on.

At a glance, some people might reject a toolkit approach. There’s a tension in using toolkits in that they bundle choices together for you. If many choices are bundled together, it’s easier to get started but harder to go far. If too few choices are bundled together, the toolkit doesn’t differ much from a general purpose language. You may recall from the Interface and Interaction Design class the article Myers (2000). That article showed a 2×2 matrix of learning threshold and utility ceiling for design tools in general. You can imagine similar constraints for InfoViz and the different communities fitting into the three cells (presumably no one wants to fit into the high learning / low utility cell).

On the other hand, a system like sense.us, shown above, can not be created with a toolkit like prefuse. How interesting, then, that sense.us was created by the creator of prefuse. Why is it that the creator of a system that makes it easy to compare different representations immediately creates something that does not take advantage of that facility? Look at sense.us and the sense.us video and see if you can identify a common theme in these two projects. Also, consider how you could jury-rig a system like sense.us without the evident integration between the panels above. Can you imagine a way to build something you could test piecemeal? Where would you get the components?

A popular solution to the learning / utility dilemma is the language processing. The point of this system is to characterize prototypes as sketches and to free development from obstacular software requirements by emulating the act of sketching. The visual contents of the Processing book, shown above, exemplify the value of the approach in that you don’t have to know exactly what the pictures mean to have an idea of what awaits you on a given page.

Shneiderman (2007), from which the above picture is drawn, provides an overview of the way InfoViz prototyping is being drawn into service in suppport of creativity. This is a high-value, but poorly understood area for scientists, general academics, and people in business. The systematic way I look at prototyping embedded in the iterative design cycle may not be needed for audiences like the trombonist pictured in the article. In these cases, the sketching paradigm enabled by Processing (not to mention the paradigms of other tools in the above picture) may allow prototyping to be embedded in other processes. Where can you imagine this happening?

You may be internalizing some of the readings on representation last week. As you develop your own framework for thinking about information representations, it may be helpful to think of these examples of developing frameworks to organize representation characteristics. You have to develop your own, and I am not recommending these, just using them as discussion aids.

The above example, found here, starts with four objectives, comparisons, relationships, distributions, and composition. From there, the chartmaker divides data, then settles on formalisms. Note that a given formalism may show up in more than one destination: the scatterplot shows up under relationships and distribution. Note also that the data here is always presumed to be what Agresti (2002) would call interval variables. Finally, only a few formalisms are shown. For instance, relationship could be extended with scatterplot matrices to show relationships between more than three variables.

A more elaborate framework is shown above. The Periodic Table of Visualization shows about a hundred methods on a display that borrows its style from the Periodic Table of Elements. When your mouse hovers over any given square of the table, an example pops up. The above snapshot was taken while my mouse hovered over the semantic networks square. As your thinking about information representation crystallizes, I expect you to value a framework like this more and more. It probably took a lot more effort and study to create than the previous example, and uses definitions and examples from literature. It includes interface features allowing a more compact overview (context) with a dynamic focus. What else can you say about this framework?

Let me just briefly comment on the inspiration that people took from Eytan’s cellular automaton. Here’s a DNA microarray, a relatively new tool for visualizing gene expression under different conditions. This tool was developed for a very particular kind of scientific visualization, but can easily be repurposed. The original use is to observe the degree of gene expression under different conditions. In this example, there are four possible effects, one each shown by red, green, yellow, and black. In addition, each of these four effects can be weak or strong. As with Eytan’s cellular automaton, it’s easy to imagine repurposing this in any system that records a large number of measurements when you know that each measurement can take on only a few values in a few categories.

Finally, here’s an example of a hierarchical menu from a recent a recent trade show. It should be clear that this is the same formalism for tree display as used in the Apple Finder Column View. It should be clear that this is a formalism that solves the problem of trying to depict a large tree in a (potentially small) resizable rectangle. Some elements in this picture are not essential to that mission, such as the curves at each level. There are also some possible additions you could consider. For example, if you have many entries at one level, you could add a way to represent how much of that level is hidden. With the Apple Finder Column View, that is accomplished by making the length of the scroll bar proportional to the hidden portion. What other ways can you think of to accomplish this?