Recently the Coding Bubbles project came out of stealth mode. The concept of a new IDE interaction model caught the attention of the software development community. InfoQ recently followed up with creator Andrew Bragdon to find out more about the project.
InfoQ: How does it feel to become a developer meme sensation in only a few short days? What are some of the more notable responses you've received?
Haha well it's been a bit surprising to see the level of excitement the project has generated online – I guess you never quite expect that. It's very gratifying, though, to see that level of interest after all the hard work we put into the project for the year and a half of development leading up to the paper submissions in late 2009.
Well I've definitely gotten a flood of email – and indeed, have not had a chance to read through all of them yet (apologies to anyone still waiting for a reply – I will definitely reply eventually!). Perhaps the most unexpected are the multiple job offers people have been sending me! There has also been a lot of interest in the beta, with a lot of emails asking about the beta, when it will be available, and many people asking if they can get their hands on it early. Another common query has been whether we can add support for other languages (Python and C/C++ seem to be especially popular).
InfoQ: You mention the bubbles metaphor on the site. That being said what was the initial inspiration for the idea?
The Code Bubbles project originally started out way back in January, 2008 when I was playing around with different ideas for using a pen to annotate and gesturally manipulate source code through a small supporting screen (Tablet PC) used flat on the desk. One of the early ideas I implemented was being able to lasso a function with the pen and then flicking with the pen to tear out a function into a floating bubble. This allowed the user to tear out bubbles from many different points in the code base and see them all at once. Once I had this implemented it became very clear to me that fragments could be beneficial for a very wide array of coding tasks, from reading and editing, to annotating and collaboration, to debugging. It was pretty exciting at the time because while I could see the potential, there was a huge amount of design and implementation work to be done in order to make something useable and scalable.
In addition to this, there has also been a lot of related work over the years to draw from. Indeed, it's important to point out that we did not invent the idea of working with fragments. The original work there is the Smalltalk environment, and later, the Squeak environment – which let you open single functions in floating child windows.
Since then, modern IDEs seem to have veered away from fragments and much more toward file-based editing. It's hard to say for certain why this was, but I think that there were a number of scalability problems with the original approach that make it unsuitable for Java. Java code tends to have long lines, which makes it difficult to fit a function in a compact space. In addition, a problem with child windows is that it requires the user to manage which windows are on top, which is fairly tedious, and all of the extra UI that comes with child windows could be seen as distracting. Finally, if you fill up your screen with windows, then you will “run out of space” so to speak.
So with Code Bubbles we have built on this earlier work by designing solutions to some of these scalability problems. To handle functions with long lines, we use syntax-aware reflow that runs in real time to wrap these long lines the way a programmer would. To handle long functions, we collapse large blocks by default, using vertical elision. To reduce the need to manage which windows are on top, we do not allow bubbles to overlap – instead, a recursive algorithm will automatically push any bubbles that overlap a moved bubble out of the way, while attempting to find a global minimum on the amount of movement needed. We also eliminated as much chrome as possible from each bubble to try to reduce visual clutter. Finally, bubbles exist in a continuously pannable 2-D virtual workspace so that if you run out of screen space, you can simply pan over to make more room, or navigate to an unused portion of the space to work on a new task. There are a number of other features we added as well, such as a transient zoom feature, lightweight grouping, and workspace tasks that also help with scalability.
InfoQ: One of the things that impressed me about the demo is the fact that you've taken the concept and applied it not only to method level editing but also other areas like debugging, code completion, reference searches, etc. Could you elaborate on that process?
Certainly—well one of the nice things about the bubbles metaphor is that it can be used for more than just reading and editing code. We call a group of onscreen bubbles a working set; working sets can be very useful for programming tools that naturally output multiple methods or locations in code. For example, debuggers often involve stepping through execution traces, so we use bubbles to display the trace onscreen, side-by-side as the user steps in and steps out of various functions.
There are many development tools that have this property of outputting multiple methods. For example, if you think about versioning and diffs, a group of bubbles could be displayed showing the methods that have changed. I can also see applying bubbles to other tools such as profilers, automatic bug finding tools, unit testing results, and so on. So in these cases, a development tool will create the working set as output rather than the user, but I think that the benefits are similar: you can now easily see many methods from different locations in the code base side-by-side without having to navigate.
Bubbles can also be used as input to a tool in cases where the user has already opened one or more bubbles onscreen. For example, we have a feature which lets the user draw a line between two open bubbles; in the backend we then perform a static call graph search and identify the shortest calling path, if any, between the two methods. We then open more bubbles inbetween to illustrate this call path. We also use the lightweight grouping functionality to allow users to query a notion of "related bubbles", that is, methods which have been grouped together with this method in the past, perhaps, by other developers. So I think that using bubbles as input to development tools or queries also makes sense.
One natural aspect of the Code Bubbles interface is that the input and output I just described can be chained together; for example if the user performs a find all references search on an identifier, a bubble stack will open to the right with the results; the user can then open a relevant method in this stack and then in turn perform another find all references search, say, which will open to the right. At this point the user can see the full history of their interactions all onscreen at once, side-by-side, making it easier and more natural to work with the branching nature of such queries.
InfoQ: What were some failed ways you tried to apply the concept to the above areas, and what concepts have you found that simply don't fit the paradigm?
That's a good question! Well, I used an iterative design process where we would design and implement initial prototypes of features, then bring in professional developers from the area and get their feedback, and then further refine the design based on that. So while I wouldn't say that we have implemented anything that didn't end up getting used in some form, there are plenty of features that went through multiple design revisions. There are also a number of features we added based on user requests.
One of the biggest requests early on was more keyboard shortcuts. Many developers who came in were heavy keyboard users, and wanted more keyboard shortcuts. This led us to add things like shortcuts to bring up the search box next to the current bubble to easily open a new function side-by-side, go to definition, etc.
Also, initially we did not have the transient zoom feature for navigating and re-arranging bubbles. Many users who came in asked for both the ability to zoom out, so they could re-arrange their workspace, but also unexpectedly, to zoom in, so they could show their coworkers things better "over the shoulder".
Another feature we added based on significant user request was the ability to export a screen to PDF. Many developers who came in suggested this would make it easier to document bugs, or to discuss features spread throughout code with the rest of their team, since they could open the relevant working set, annotate it, and then share it by email or upload it to a bug tracking system.
InfoQ: The website mentions the project being built on Eclipse. Is there any thought of contributing the project as open source to the Eclipse foundation (I see nothing about licensing on the website)? How about further development as a commercial product?
Open sourcing the project is definitely something that we hope to do this year. I would also like to add in a plug-in architecture soon to support developers in extending the environment to better suit their needs.
The current plan is for it to be a free, non-profit system that you can simply download and use with your existing Eclipse installation. We would certainly love to sync up with the Eclipse team about possibly working together.
InfoQ: Given the Eclipse foundation, would the Bubbles components work with other languages such as Ruby/Groovy that have Eclipse support?
Definitely! In theory, any language that is well-supported by Eclipse we could support. It actually does require some work to add a language, though. The syntax-aware reflow we use to wrap long lines is based on the parse trees (abstract syntax trees) for the language, and some other things need per-language customization.
This is definitely something we would like to do soon, though!
InfoQ: Where do you want to go next with the project?
The next important step for us is to release the beta so developers can try it out at home and work, and send us feedback. If this is successful, it will allow us to continue the iterative design process – but on a much larger scale, where we could potentially roll out a new feature and then get feedback on it right away.
Our current plan is to do a limited release in mid April and then slowly expand the size of the beta over the next few months as we add more features and stabilize the system. (By the way, [shameless plug], you can sign up for the beta at codebubbles.org). We then hope to open it up for general download
