from the whiteboard to the development environment. This separation also causes poor task support. For example, Jane’s code search and notepad diagram are not tied together in any way. The two can easily get out of sync and cannot be stored or retrieved together, as when Jane’s diagram was available during task resumption but her search results were gone.

Second, there is no transition be-
tween team-level documentation
and task- or conversation-specific
diagrams. For example, Jane has to
reproduce parts of the poster on the
whiteboard in order to answer Joe’s
specific questions. Third, there is a
lost opportunity to help deal with the
disorientation Jane feels when con-
fronting all the open documents on
resuming her task.

Table 1. information needs that are related to diagramming behavior.

1. What code could have caused this behavior? 1. What is the purpose of this code?

2. What is statically related to this code? 2. What is the program supposed to do?

3. What code caused this program state? 3. Why was this code implemented this way?

4. What are the implications of this change?

no visual transition to show where the jump landed. The more she navigates, the greater the pileup of document tabs. These navigation steps are not just for editing the code. Software developers also have a frequent need for information during their programming tasks. 7, 8 To try to find answers, they bro wse around the code and other documents, which adds both relevant and irrelevant documents to the environment’s working set. With so much discontinuous navigation, a developer can easily become disoriented.

Better support for code diagrams in the development environment could support code understanding and communication, and could serve as a “map” to help keep developers oriented. The software visualization community has previously explored different types of maps, such as zoomable box-and-line diagrams9 and cityscapes, 10 for tasks such as program understanding and analyzing