Because developers are frequently blocked and interrupted in their work, they often have to return to tasks that have been put aside, sometimes for minutes, sometimes for months. Today's development tooks place a large burden on a developer to find the documents they work on by remembering a lot of symbol names -- the names of projects, files, bug reports, classes, methods, and on and on. This memory tax means that developers spend a lot of time searching to find the documents they previously worked on. In one line of our research, we are exploring the use of spatial representations of development documents to allow developers to use spatial memory to find them. We are looking at these research questions:

• How do developers depict their code when they explain it to others?
• What are the navigation patterns developers exhibit when working with code?
• What representations of code and other artifacts best support developers' work?

Projects

Code Canvas

We are working on a successor to Code Thumbnails in which the spatial representation is the heart of the IDE's user experience. More details can be found on Kael Rowan's blog.

Code Thumbnails

While Software Terrain Maps (below) provides a compact representation of code for forming spatial memory, the representation is unintuitive and must be learned. Instead, building on the Data Mountain, Code Thumbnails intuitively represents code with a shrunk down version of the source files themselves. To aid intra-file navigation, we add a thumbnail image of the file to the scrollbar, which makes any part of the file one click away. To aid interfile navigation, we provide a desktop of file thumbnail images, which make any part of any file one click away. We did a formative evaluation of the design with eleven experienced developers and present the results.

Ohana Map

In the summer of 2006, Gina Venolia and Mauro Cherubini ran a series of surveys and interviews on why and how developers use visual depictions of their code. We found that diagrams that documented design decisions were often externalized in the temporary drawings and then subsequently lost. Most of the diagrams had a transient nature because of the high cost of changing whiteboard sketches to electronic renderings. Current visualization tools and the software development practices that we observed do not solve these issues, but these results suggest several directions for future research.

Software Terrain Maps

As experienced developers navigate around unfamiliar code, they often become disoriented. Indeed, in a recent observation study, we even saw a participant not recognize a method he had visited just a minute beforehand. It would be great if source code had a sense of "place" that would allow us to use our spatial memory when navigating, just as we do when navigating physical terrains. Software Terrain Maps are a prototype visualization based on the metaphor of cartographic maps, which are continuous (no wasted space), have enough visual landmarks to allow the viewer to recognize locations perceptually rather than cognitively, and lend themselves to data overlay.