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?