Debugger Canvas: Industrial experience with the code bubbles paradigm

Abstract

At ICSE 2010, the Code Bubbles team from Brown University and the Code Canvas team from Microsoft Research presented similar ideas for new user experiences for an integrated development environment. Since then, the two teams formed a collaboration, along with the Microsoft Visual Studio team, to release Debugger Canvas, an industrial version of the Code Bubbles paradigm. With Debugger Canvas, a programmer debugs her code as a collection of code bubbles, annotated with call paths and variable values, on a twodimensional pan-and-zoom surface. In this experience report, we describe new user interface ideas, describe the rationale behind our design choices, evaluate the performance overhead of the new design, and provide user feedback based on lab participants, post-release usage data, and a user survey and interviews. We conclude that the code bubbles paradigm does scale to existing customer code bases, is best implemented as a mode in the existing user experience rather than a replacement, and is most useful when the user has a long or complex call paths, a large or unfamiliar code base, or complex control patterns, like factories or dynamic linking.

An Observational Study of How Experienced Programmers Annotate Program Code

“…There are tools that allow graphical representations for code (e.g. [19,20]). These tools should maintain the spatial positioning of the elements to help programmers remember where things are.…”

“…Examples of support provided by tools include alternate visualization s (e.g. graphs and diagrams), debugging support and syntax highlighting [19,20]. There are also tools that allow people to draw diagrams and annotate their code [21,22].…”

The Moldable Debugger: A Framework for Developing Domain-Specific Debuggers

“…While other approaches, like deet [23] and Debugger Canvas [16], support domainspecific user interfaces for different domains, they do not offer an easy and rapid way to develop such domain-specific user interfaces.…”

“…Even with just two different types of debuggers, DeLine et al noticed that users needed to switch between them at run time [16]. This happened as users did not know in advance in what situation they would find themselves in during debugging.…”

“…-providing debuggers with domain-specific user interfaces that do not necessarily have a predefined content or a fixed layout [16].…”