Today's widely deployed painting applications use a linear undo model that allows users to backtrack previous operations in reverse chronological order. This undo model is not useful if the user has performed desired operations after undesired ones. Selective undo, in contrast, allows users to select specific operations in the past and only undo those, while keeping the remaining operations intact. Although selective undo has been widely explored in the context of text editing and object-oriented drawing, we explore selective undo for painting (bitmap) editing, which has received less attention and introduces many interesting user interface design challenges. Our system, called Aquamarine, explores the script model for selective undo, where selectively undone operations are skipped in the history, rather than the more explored inverse model, which puts an inverse of the selected operations at the end of the history. We discuss the design implications and show through two informal user studies that selective undo is usable and desirable

Programmers often need to revert some code to an earlier state, or restore a block of code that was deleted a while ago. However, support for this backtracking in modern programming environments is limited. Many of the backtracking tasks can be accomplished by having a selective undo feature in code editors, but this has major challenges: there can be conflicts among edit operations, and it is difficult to provide usable interfaces for selective undo. In this paper, we present AZURITE, an Eclipse plug-in that allows programmers to selectively undo fine-grained code changes made in the code editor. With AZURITE, programmers can easily perform backtracking tasks, even when the desired code is not in the undo stack or a version control system. AZURITE also provides novel user interfaces specifically designed for selective undo, which were iteratively improved through user feedback gathered from actual users in a preliminary field trial. A formal lab study showed that programmers can successfully use AZURITE, and were twice as fast as when limited to conventional features.

Previously, we presented our technique for visualizing fine-grained code changes in a timeline view, designed to facilitate reviewing and interacting with the code change history. During user evaluations, it became evident that users often wanted to see the code changes at a higher level of abstraction. Therefore, we developed a novel approach to automatically summarize fine-grained code changes into more conceptual, higher-level changes in real time. Our system provides four collapse levels, which are integrated with the timeline via semantic zooming: raw level (no collapsing), statement level, method level, and type level. Compared to the raw level, the number of code changes shown in the timeline at each level is reduced by 55%, 77%, and 83%, respectively. This implies that the semantic zooming would help users better understand and interact with the history by minimizing the potential information overload.

Programming often involves reverting source code to an earlier state, which we call backtracking. We performed a longitudinal study of programmers' backtracking, analyzing 1,460 hours of fine-grained code editing logs collected from 21 people. Our analysis method keeps track of the change history of each abstract syntax tree node and looks for backtracking instances within each node. Using this method, we detected a total of 15,095 backtracking instances, which gives an average backtracking rate of 10.3/hour. The size of backtracking varied con-siderably, ranging from a single character to thousands of char-acters. 34% of the backtracking was performed by manually deleting or typing the desired code, and 9.5% of all backtracking was selective, meaning that it could not have been performed using the conventional undo command present in the IDE. The study results show that programmers need better backtracking tools, and also provide design implications for such tools.

Programmers often need to backtrack, but backtracking support in modern programming environments is limited. Previously, we have conducted a series of studies, which discovered that backtracking in programming is in fact prevalent and programmers need better backtracking tools. In this demonstration, we will present our backtracking tool called AZURITE, which provides selective undo and history search and visualization features in the Eclipse code editor. The demonstration will include the user interface presented in our previous work, as well as the new features added in response to user feedback.

Programmers often need to backtrack while coding, yet there is only limited support for backtracking in modern programming tools. Our study results confirmed the prevalence of backtracking and identified several problems programmers face while backtracking. To mitigate these problems, we are building an IDE plug-in aimed at providing better support for backtracking by combining a selective undo mechanism, novel visualizations, and code change history search features. We envision that this approach will help programmers perform backtracking tasks more easily.

Conventional version control systems save code changes at each check-in. Recently, some development environments retain more fine-grain changes. However, providing tools for developers to use those histories is not a trivial task, due to the difficulties in visualizing the history. We present two visualizations of fine-grained code change history, which actively interact with the code editor: a timeline visualization, and a code history diff view. Our timeline and filtering options allow developers to navigate through the history and easily focus on the information they need. The code history diff view shows the history of any particular code fragment, allowing developers to move through the history simply by dragging the marker back and forth through the timeline to instantly see the code that was in the snippet at any point in the past. We augment the usefulness of these visualizations with richer editor commands including selective undo and search, which are all implemented in an Eclipse plug-in called “Azurite”. Azurite helps developers with answering common questions developers ask about the code change history that have been identified by prior research. In addition, many of users' backtracking tasks can be achieved using Azurite, which would be tedious or error-prone otherwise.

Code completion menus have replaced standalone API browsers for most developers because they are more tightly integrated into the development workflow. Refinements to the code completion menu that incorporate additional sources of information have similarly been shown to be valuable, even relative to standalone counterparts offering similar functionality. In this paper, we describe active code completion, an architecture that allows library developers to introduce interactive and highly-specialized code generation interfaces, called palettes, directly into the editor. Using several empirical methods, we examine the contexts in which such a system could be useful, describe the design constraints governing the system architecture as well as particular code completion interfaces, and design one such system, named Graphite, for the Eclipse Java development environment. Using Graphite, we implement a palette for writing regular expressions as our primary example and conduct a small pilot study. In addition to showing the feasibility of this approach, it provides further evidence in support of the claim that integrating specialized code completion interfaces directly into the editor is valuable to professional developers.

In this paper, we propose a complementary technique called active code completion. When the developer invokes the code completion menu, the editor looks for a palette definition associated with the type of the expression being entered. If found, an option to use this palette is added to the code completion menu. When the developer selects this option, source code is not inserted immediately. Instead, the palette definition takes control of the code completion interface. The developer can then interact with this interface to provide parameters and other information related to her intent, and receive immediate feedback about the effect these choices will have on the object's behavior. When the developer indicates that she is satisfied with these choices, the palette generates code that is inserted at the cursor.