Code Canvas vs. Code Bubbles vs. Debugger Canvas

You may have seen my previous comparison of Code Canvas vs. Diagrams/Visualizations, but sometimes people also ask me “What is the relationship between Code Canvas and Debugger Canvas?”, or “Is Debugger Canvas the same as Code Bubbles?”.  Here are my personal thoughts on some of the high-level differences between the three:

Code Canvas: Shows source code and relationships among source code on a zoomable canvas in a spatially stable and meaningful way. It allows code to be edited directly on the canvas instead of in separate tabbed editors like traditional IDEs. Semantic zoom is used to zoom out to view the entire system and its architecture in a smooth “deep zoom” kind of way. Information overlays like references, code coverage, and execution traces are displayed directly within the canvas instead of a separate diagram or window. The position of each item on the canvas has meaning in the context of the overall software diagram and is not placed arbitrarily. Each item on the canvas has one and only one location and is never duplicated (although it can be moved). Development teams share and collaborate over a single master canvas in the same way they agree on the locations of files in their source control directory tree. The lifetime of the canvas is mostly expected to be permanent and become a valued asset of the project. Spatial memory is a primary focus.

Code Bubbles: Replaces the entire IDE with a single canvas. It contains source code fragments but also can contain tool windows, property grids, tear-off queries, work items, email, etc. Some windows (like menus or property grids) may appear just temporarily in a spatial radius around the “current item” instead of always being visible on the canvas. The position of each item on the canvas is meant to maximize organization or screen real-estate for the current task or environment. Items (including source code fragments) can be duplicated and appear in multiple places at once. Development teams may give copies of canvases to team-mates or new hires but they are usually developer-specific. The lifetime of the canvas is usually temporary and/or task-specific. Spatial memory may be relevant but is not a primary focus.

Debugger Canvas: Shows source code fragments on a canvas for each step of a program being debugged, with arrows indicating where one method stepped into another during that debugging session. It also contains non-code items such as “locals” windows on the canvas and allows debugging-specific operations such as taking a snapshot of the local variables. The position of each item on the canvas is related directly to the order (or thread) in which it was called during a debugging session. The user has the option of duplicating source code fragments on the canvas each time the code is stepped into, or they can choose to reuse the same fragment over and over if it is called more than once. Developers may send static screenshots or copies of the canvas to teammates but otherwise canvases are not shared. The lifetime of the canvas is only meant to last for a single debugging session. Spatial memory is only a focus in that it is meant to be consistent with the order of execution of the program.