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