Restructuring Software with Gestures - Semantic Scholar

Restructuring Software with Gestures Emerson Murphy-Hill and Moin Ayazifar

Andrew P. Black

North Carolina State University Raleigh, North Carolina, USA Email:{emerson,mayazif}@csc.ncsu.edu

Portland State University Portland, Oregon, USA Email:[email protected]

Abstract—Refactoring is the process of changing the structure of code without changing its meaning, and is a frequent practice among developers. Although programmers refactor frequently, they usually do not use refactoring tools to automate this process. We argue that the need to recall the name of a refactoring before the appropriate tool can be invoked makes it unnecessarily hard to initiate a refactoring with a tool. Conventional ways of initiating a tool also make it hard to transition from novice tool user to expert tool user. The contribution of this paper is a memorable mapping from gestures to refactorings, and an implementation of that mapping in the form of marking menus. In the first reported experiment to explore the effect of the position of items in marking menus on people’s ability to infer the location of those items, we asked 16 programmers to complete a paper-based evaluation of our mapping. The results suggest that programmers can infer the gesture that will invoke the appropriate refactoring tool, even if they do not know the name of the refactoring. We also illustrate how marking menus might be used for refactoring during development with two other small studies.

I. I NTRODUCTION Fowler characterizes refactoring as the process of changing the structure of existing code while preserving its functionality [1, p. xvi]. While the term “refactoring” is fairly new, it captures what programmers have done for a long time: ever since programs have been structured, programs have been re-structured. Refactoring is critical to software development: it allows programmers to adapt software to the changing demands of customers, markets, and managers. In industry, refactoring is practiced frequently, regularly, and in support of higher-level programming goals such as fixing bugs and adding features [2], [3]. Because of the importance of refactoring, many integrated development environments now include tools that semiautomate the process, such as Eclipse (http://eclipse.org), IntelliJ IDEA (http://www.jetbrains.com/idea), NetBeans (http://netbeans.org), Visual Studio (http://microsoft.com/visualstudio), and Xcode (http://developer.apple.com/tools/xcode). An example of a refactoring tool in such an environment is the P ULL U P M ETHOD tool, which moves a method from a class to its superclass and makes sure that all references to that method will continue to be valid after the method is moved. Although previous research has shown that programmers refactor frequently, programmers do not use refactoring tools frequently [2]. This underuse signals a missed opportunity: because refactoring is frequent, it follows that a large number

of refactorings are being performed by hand, unnecessarily slowing-down software development and increasing the chance that a bug might be introduced. Much research has been performed to promote refactoring tool use by improving the user interface of the tools, including improving the programmers’ ability to identify opportunities for refactoring [4], to select code as input to a refactoring tool [5], to refactor code spread across a code base [6], and to understand the errors that refactoring tools sometimes produce [5]. However, before programmers can benefit from any of this research, they must start the refactoring tool. We call the process of communicating to the programming environment which refactoring tool it should start the initiation step — the zeroth step in the process of refactoring. Initiation is an underexplored area of research in the user interface of refactoring tools. Programmers are typically expected to initiate a refactoring tool using a linear menu or by pressing a hotkey; Figure 1 shows the refactoring menu in Eclipse. As we argue in the next section, neither of these mechanisms is ideal. Instead, we propose initiating refactoring tools using gestures. The contribution of this paper is a novel mapping from gestures to refactorings: we discuss why such a mapping it is needed, describe our implementation, and report the results of three evaluations. II. P ROBLEMS WITH I NITIATION The conventional initiation mechanisms — context menus, application menus, and hotkeys — have two problems that make them less than ideal. Problem 1. Naming: Suppose that a programmer wants to make a code change that is a refactoring. How does she know which refactoring tool to use to perform that change? Typically, she must recall the name of the refactoring that she wants to perform, such as R ENAME, E XTRACT M ETHOD, or I NTRODUCE FACTORY, and then find that name in a menu. There are two problems with this approach. If the programmer is sure of the name of the refactoring, she must still find it in what may be a long menu (see Figure 1). We have some evidence of this problem from a survey of programmers; when asked why they choose not to use refactoring tools, one respondent said that the “menu is too big sometimes, so searching [for] the refactoring takes too long” [7]. However, we hypothesize that the more serious problem is that the names of refactorings are somewhat

a hotkey (expert behavior) is known to be a slow process [9]. In the case of refactoring tools, transitioning from menus to hotkeys is made difficult by the same problem that we identified above: the need to remember the name that the environment gives to the refactoring. The mapping from code transformation to hotkey is indirect: the programmer must start with the idea of the transformation that she intends to perform, such as “take this expression and assign it to a temporary variable”, recall the name of the corresponding refactoring (E XTRACT L OCAL VARIABLE), and then map that name to a contrived hotkey (remembering that Shift+Alt means refactor, and that L stands for “Local”). III. A M APPING FROM G ESTURES TO R EFACTORINGS To solve the naming problem, we have created a mapping from gestures to refactorings. This mapping forms a consistent foundation for initiating refactoring tools. It is based on the observation that the structural nature of many refactorings can be associated with a gesture using a consistent directional metaphor. Our mapping derives from three rules that determine the gestural direction of a refactoring. • Directional refactorings are assigned their respective direction, so, for example, P ULL U P F IELD is assigned the up gesture ( ). This rule capitalizes on the convention that class hierarchies are shown with superclasses above subclasses. • Refactorings that are inverses are assigned opposite directions, so, for example, I NLINE M ETHOD ( ) is opposite E XTRACT M ETHOD ( ). This rule makes use of the observation that the inverse of many refactorings is another refactoring. • Refactorings that are conceptually similar are assigned the same gesture, so, for example, the same gesture is used for I NLINE M ETHOD and I NLINE L OCAL VARI ABLE ( ). Which refactoring is initiated for a given gesture depends on the context in which the gesture is used. This rule capitalizes on similarities between refactorings. We hypothesize that a mapping following these rules will help developers infer a consistent mental model after being exposed to only a small number of examples, such as by invoking a refactoring tool a few times using gestures. Inference would assist in solving the naming problem, because it would allow the programmer to initiate a refactoring without first learning its name. We validated this hypothesis with an experiment, described in Section V. The mapping from gestures to refactorings can be used to initiate refactoring tools in a number of ways. One way is with hotkeys: the programmer selects a program element to be refactored, presses a key to bring up the menu, and then presses the up-, down-, left-, or right-arrow key to “gesture” towards a refactoring. Another way is to allow the programmer to gesture using the mouse. Further possibilities include gesturing with the eye, hand, or stylus. In the next section, we describe how we combined mouse and hotkey gestures using marking menus.




Fig. 1.

A refactoring menu in Eclipse.

capricious and vary from one environment to another. For example, Fowler’s I NTRODUCE E XPLAINING VARIABLE [1] is called E XTRACT L OCAL VARIABLE in Eclipse. We observe that the names of the refactoring tools are a distraction to the programmer, who need realize, for example, only that her code would be improved if a long sub-expression is assigned to a meaningfully-named local variable. In a follow-up interview to our recent research on programmers’ refactoring behavior [2], one programmer complained about this problem explicitly: “I may know what I’m doing is refactoring, but may not know what this particular refactoring action is called within the tool”. Thus, by forcing the programmer to learn (or guess) the name that the environment gives to that refactoring before she can start the refactoring tool, the environment makes tool initiation unnecessarily burdensome. Problem 2. Transitioning from Novice to Expert: Assuming that the programmer knows the name of the refactoring that she wants, she can select that refactoring from a context or application menu. However, such linear menus can be slow [8] because the user must take significant time to navigate to the menu, then through the menu, and finally to point at the desired menu item. Thus, to initiate a tool faster, the programmer may instead want to use a “hotkey”, that is, a combination of keypresses on the keyboard. However, transitioning from using the menu (novice behavior) to using





Fig. 2. Two marking menus for refactoring, showing applicable refactorings for a local variable and a method.

IV. M ARKING M ENUS FOR R EFACTORING To demonstrate our mapping, we have added marking menus as a new user-interface element for the existing Eclipse refactoring engine; our implementation is based on SATIN [11]. A marking menu is a special kind of pie menu; it is similar to a context menu except that items appear around a circle instead of in a linear list. Two examples are shown in Figure 2. Our marking menus are invoked like standard context menus, using a dedicated mouse button or hotkey; we presently use the middle mouse button. Because marking menus are context sensitive, the menu displayed depends on the kind of program element that has been selected. For example, as Figure 2 shows, one menu will appear when the selection is a variable name, and a different menu will appear when the selection is a method name. Moreover, the user may transition to expert behavior by “mousing ahead” and gesturing in the direction of the desired menu item, even if that item has not yet been drawn on the screen. In this way, marking menus allow programmers to smoothly transition from beginner behavior (point-and-click) to expert behavior (mouse-ahead). We encourage the reader to watch our screencast or try marking menus for refactoring at http://multiview.cs.pdx.edu/refactoring/activation. In addition to allowing the programmer to smoothly transition from beginner to expert, implementing our mapping in the form of marking menus has additional advantages. Marking menus are significantly faster than linear menus because items are selected by direction alone, rather than by direction and distance [8]. Moreover, after frequent use of a menu item, muscle memory helps users remember to gesture in the direction in which menu items are located [12]. Gestures are efficient during programming as well; Burnett and Gottfried have shown that people who use gestures to issue programming commands can program faster and with fewer errors [13]. Because of the mapping, refactoring appears to be one of the applications of marking menus that Callahan and colleagues say “seem to fit well into the mold of the pie menu design,” and for which they showed that pie menus have a distinct speed advantage [8].

The main limitation of our implementation of marking menus for refactoring is that our marking menus are restricted to four items per context; submenus are not supported. Of 22 refactorings that can be initiated via a linear menu in Eclipse, 11 can be initiated with our marking menus; our menus also support 3 additional refactorings not currently in Eclipse, as shown in Table I. The restriction to four items per menu means that certain refactorings do not appear on our marking menus, especially refactorings that have no spatial mapping, such as R ENAME. Indeed, our previous empirical study on which refactorings programmers perform suggests that R ENAME is a very common refactoring [2]. Using that data, the refactorings that can be performed with our marking menus account for about 43% of total refactorings performed that have tool support in Eclipse. Excluding R ENAME, that number rises to 61%. There are several reasons that we do not view our incomplete coverage of the space of refactorings as a significant problem. First, we argue that completeness at the expense of simplicity is not always desirable when it comes to user interfaces. Second, programmers currently use several mechanisms for initiating different kinds of refactoring tools [10], and thus programmers may be willing to use some other initiation mechanism in conjunction with marking menus. Third, the incompleteness is not fundamental to our approach; it is possible to extend marking menus for refactoring to provide for the initiation of all refactorings, as we discuss in Section VIII. V. C ONTROLLED E XPERIMENT This section describes an experiment to test the hypothesis that programmers can infer our mapping. Our main result — that programmers can indeed infer the mapping — implies that programmers will be able to use that mapping to initiate refactoring tools, even if they do not know the name of the refactoring tool that they want. In addition to serving as a mechanism to test our hypothesis, we chose to perform this particular experiment for two reasons. First, to our knowledge, it is the first experiment of its kind: no other reported experiment has evaluated the effect of item placement on people’s ability to infer where items appear. Second, by performing a laboratory experiment, rather than a field study, we are able to more easily isolate the cause of improved programmer performance. For example, suppose that we had chosen to do a field study in which we compared marking menus using our mapping with linear menus and hotkeys. Suppose further that the study showed increased performance or adoption of refactoring tools. However, we would still be unable to ascertain the source of the improvement: it might be due to the mapping, to the menus, or to a simple novelty effect, where programmers exhibit better performance because of increased interest. A. Methodology In this experiment, programmers were asked to memorize the direction (left, right, top, or bottom) of a refactoring on a

TABLE I H OW REFACTORINGS CAN BE INITIATED IN OUR CURRENT IMPLEMENTATION OF MARKING MENUS . Refactoring Tool Rename Move Change Method Signature Extract Method Extract Local Variable Extract Constant Inline Convert Anonymous Class to Nested Convert Member Type to Top Level Convert Local Variable to Field Extract Superclass Extract Interface Use Supertype Where Possible Push Down Pull Up Introduce Indirection Introduce Factory Introduce Parameter Object Introduce Parameter Encapsulate Field Generalize Declared Type Infer Generic Type Arguments Convert Nested to Anonymous Increase Visibility Decrease Visibility

can be initiated by. . .

marking menu. In the training phase, programmers were given a paper packet containing 9 pages. Each page contained an initial piece of code, a refactored piece of code, and a picture of a marking menu for refactoring; the associated refactoring was highlighted on one of the four menu quadrants (Figure 3, left). We told programmers to try to associate the before-andafter code with a direction. We gave programmers 30 seconds to make this association to ensure that they were spending most of their time understanding the refactoring, and that little time was available for memorization; interviewing pilot experiment participants informally confirmed this. We used before-and-after code to identify the refactoring, rather than using its name. There were three reasons for this: 1) programmers who had no knowledge of refactoring terminology could still participate in the experiment; 2) our choice of refactoring names would not confuse programmers who had experience with refactoring, but who used different terminology; and 3) by asking programmers to think of a refactoring as a code transformation rather than as a name in a book, the experiment would more closely match the practice of refactoring in the wild. In the testing phase immediately following the training phase, the programmers were given the same 9 pages, but in a different order and with the labels on the marking menus removed (Figure 3, right). Within a total of 5 minutes, we told programmers to choose where the refactoring would appear on the marking menu. Additionally, programmers were asked to infer the direction of a refactoring that they had not seen during the training period. The refactoring to be guessed was E XTRACT L OCAL VARIABLE, which, according to our mapping, should appear in the same direction as the C ONVERT

Linear Menus Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No

Hotkeys Alt+Shift+R Alt+Shift+V Alt+Shift+C Alt+Shift+M Alt+Shift+L Alt+Shift+I

Marking Menus

Right ( ) Right ( )

)

Left ( Right ( Right ( Right (

) ) )



Bottom ( ) Top ( ) Right ( ) Right ( )




Right ( )

 

Left ( ) Right ( ) Left ( )

L OCAL TO F IELD, E NCAPSULATE F IELD, and I NTRODUCE I NDIRECTION, three refactorings that the subjects had seen during training. More information about this experiment, including the test materials and the resulting data set can be found at http://multiview.cs.pdx.edu/refactoring/experiments. B. Subjects We recruited 18 programmers to participate in this experiment. In an attempt to sample a diverse population, these programmers were recruited from three sources. Seven were students from a graduate programming class on design patterns, six were computer-science research assistants, and five were programmers from industry. To expose the programming class to the concept of refactoring, the first author of this paper gave students a 20-minute presentation on refactoring two weeks prior to the experiment. Two subjects were excused from the set of subjects from the programming class because one was not familiar with Java code and one did not follow directions during the experiment; this left a total of 16 participants. C. Theory The key to this experiment is how we test our theory that programmers can infer our mapping. We assume that the ability to infer our mapping arises from programmers’ ability to create and use a mental model that explains the directions of refactorings. Our experiment is similar to an experiment conducted by Kieras and Bovair [14], in which they showed that users could learn, retain, and execute operations faster on a simple physical device when the users were taught to use a mental model of the device. This group of users, called the “model group,” performed significantly better than the “rote group,” who were taught by rote memorization.

Fig. 3. A training page (left) and associated testing page (right); in each, code before-and-after refactoring at left. Code to-be-refactored is highlighted in black, and changes are in yellow.

Our experiment and underlying theory is similar to Kieras and Bovair’s. In our experiment, within each set of subjects (students, research assistants, industrial programmers), each programmer was randomly assigned to one of two groups. In the model group, programmers were trained on marking menus whose items were placed according to our mapping. In the rote group, programmers were trained on marking menus whose items were placed in a manner that violated each rule in our mapping. In this way, programmers in the rote group would be forced to rely exclusively on memory recall, whereas programmers in the model group would have, according to our hypothesis, the benefit of inference from their mental model. Thus, the difference between the two groups is attributable to programmers’ ability to infer our mapping. Our methodology is a variant of Wobbrock and colleagues’ study on the guessability of gestures [15], where the authors compared two gesture sets against one another for guessability using “accuracy attainable after minimal exposure” [16]. In that paper, the authors found that their new gesture set was more easily guessed than an existing gesture set. Similarly, our experiment evaluates the inferrability of our mapping. D. Results The results of the experiment are shown in Figure 4. Overall, subjects in the rote group correctly chose a median of 3 refactoring directions, while subjects in the model group correctly chose a median of 7.5 refactoring directions. The difference is statistically significant (p = .011, df = 1, z = 2.553

using a Wilcoxon rank-sum test). Compared to pure guessing, where subjects would have correctly guessed a mean of 2.25 refactoring directions, the rote group performed slightly better (mean=3.1), while the model group performed substantially better (mean=6.6). Furthermore, six out of the eight subjects in the model group correctly inferred the direction of the refactoring that they had not seen during training; in comparison, we would expect that if subjects had simply guessed the direction, only two out of eight would have chosen correctly1 . E. Threats to Validity This experiment has several limitations. First, subjects were asked to memorize the direction of 9 refactorings, which represent only about one-tenth of the refactorings cataloged by Fowler [1]. The effect of trying to recall the full catalog of refactorings is unclear. Second, we cannot easily explain the outliers in the data set (one overperforming rote group subject and two underperforming model group subjects, shown in Figure 4). It may be that some programmers can easily recall the direction of a refactoring, regardless of its placement, and that some programmers have difficulty recalling the direction even when the refactoring is placed according to our mapping. Third, the experiment was conducted in such a way that it is 1 We do not report the number of rote group subjects who correctly guessed because in that environment, there is no unambiguous way to define the “correctness” of a guess.

subject count

3

school

Model (median=7.5) Rote (median=3)

2

research

1

industry

0

1

2

3

4

5

6

7

8

total refactorings placed correctly out of 9

9

Fig. 4. A histogram of the results of the marking menu experiment. Each subject is overlaid as one stick figure. Subjects from the model group who correctly guessed the refactoring that they did not see during training are denoted with a dashed oval.

difficult to ascertain which of the three mapping rules was most helpful.

longitudinal study with a single software developer previously unfamiliar with marking menus.

F. Discussion

A. Methodology

The results confirm our hypothesis that programmers can infer our mapping because programmers in the model group more often chose the correct direction for refactorings than programmers in the rote group. This conclusion is strengthened by the ability of the majority of the subjects in the model group to choose the correct location of a refactoring on which they had not been trained. We postulate that the ability to infer our mapping can help programmers to initiate refactoring tools, and, in the long run, improve their adoption.

To perform this evaluation, the second author performed a development task using marking menus for refactoring. The developer has five years of experience with the Java programming language, mostly using the IntelliJ IDEA and NetBeans development environments. He was familiar with refactoring and had previous refactoring experience using the standard linear refactoring menus in IntelliJ IDEA and NetBeans. He had no previous experience with marking menus. This evaluation was done as a part of a graduate course project. During this time, he used marking menus for refactoring as well as linear menus for refactoring during Java software development activities. From the beginning of the evaluation, the developer kept a journal of this experiences and the difficulties he encountered using the new environment and marking menus for refactoring. Overall, he estimates that he spent approximately 30 hours of total development time over the course of four weeks. The development goals were (1) to improve the user interface of marking menus for refactoring according to the feedback from developers during the usability evaluation described in Section VI, and (2) to make marking menus for refactoring compatible with the latest version of Eclipse (Helios 3.6.2) and the Linux operating system. The research goal was to use marking menus for refactoring in the development process and to study the effects of using such a tool on a developer who was unfamiliar with marking menus for refactoring.

VI. L IGHTWEIGHT U SABILITY E VALUATION To get early developer feedback on how marking menus for refactoring might be used by software developers, we conducted semi-structured developer interviews at the O’Reilly Open Source Convention in Portland, Oregon. After showing 15 experienced Java developers short demonstrations of marking menus for refactoring, on average they estimated that they would use marking menus for refactoring and hotkeys equally often, but would use marking menus for refactoring significantly more than linear menus for refactoring. Participants also had two main complaints about the menus. One was that the menus were unattractive and bulky, obscuring a significant amount of code without providing a significant amount of information. Participants reported that empty menu items that contained no refactorings were distracting, and should be either de-emphasized or eliminated altogether. VII. L ONGITUDINAL E VALUATION In our third evaluation, our goal was to qualitatively describe the longer-term effect of using marking menus for refactoring during software development. To do so, we conducted a

B. Results Despite the fact that the developer had prior experience of refactoring, he found it challenging and burdensome to

transition to using refactoring tools in Eclipse — an integrated development environment that was new to him. Here we discuss three of the problems experienced by the developer while using Eclipse’s linear refactoring menu. 1) Refactoring names differed between Eclipse and Intellij IDEA; this confused the developer. For instance, G ENER IFY in IntelliJ IDEA appeared as I NFER G ENERIC T YPE A RGUMENTS in Eclipse; I NTRODUCE F IELD appeared as C ONVERT L OCAL VARIABLE TO F IELD. 2) The order in which items appear in the linear menu varies between development environments. The different orders increased the time required to find and navigate to the menu item for the appropriate refactoring. Using marking menus for refactoring and knowing the rules for positioning refactorings on the menu helped the developer infer the direction of certain refactoring tools immediately, and thus ameliorated problem 1. For instance, the developer inferred the direction for C ONVERT L OCAL VARIABLE TO F IELD immediately, since it was opposite to the direction for I NLINE. Problem (2), which made it hard to find the right refactoring tool in the linear menu, persisted even after several weeks development in Eclipse. In contrast, the developer found that gesturing using marking menus was a faster way to initiate refactoring tools. Moreover, gesturing became even faster with use. After a time, the developer was sometimes able to gesture towards a desired refactoring without reading the name of the tool. The developer also experienced some downsides to marking menus for refactoring while using them: 1) Only four refactoring tools can be accommodated in our marking menus. Consequently, wherever more refactoring tools are applicable, not all of them can be placed in one marking menu. In such cases, the developer had to switch between marking menu and linear menu; this was an inconvenience that made him reluctant to use the marking menus on a number of occasions. During the course of development, based on notes from his journal, the developer estimates that about two-thirds of the uses of the refactoring tools were through marking menus; The developer used hotkeys for R ENAME and M OVE refactorings, and linear menus for the remaining refactorings. 2) The developer sometimes felt constrained by the marking menus’ strict adherence to the mapping, and that some flexibility in diverging from the mapping may be beneficial to their utility. For example, no refactoring item appeared in the direction opposite of E NCAPSULATE F IELD, because there is no natural opposite of this refactoring for fields. While there were useful refactorings that could have occupied this space — R ENAME, for instance — the mapping dictates that none should fill that space. 3) The developer inferred that the of up gesture initiated tools that expand the code to the outside of current class (e.g. P ULL U P M ETHOD, P ULL U P F IELD), and inferred

that the right direction expanded code within the current class (e.g. C ONVERT L OCAL VARIABLE TO F IELD, E XTRACT L OCAL VARIABLE, E XTRACT M ETHOD and I NTRODUCE I NDIRECTION). Using this mental model, the developer inferred that C ONVERT M EMBER T YPE TO T OP L EVEL, which converts an inner class to a top level class in a new file, should be placed at the top of a menu. But the mapping actually placed this refactoring on the right side of the marking menu, which confused the developer. Overall, the developer found that the position of items on marking menus for refactoring were easier to infer compared to linear menus, and helped the developer to access refactoring tools faster and more conveniently over the long term. The developer could stay focused on the code when he used marking menus for refactoring, as opposed to linear menus, which were distracting. However, the absence of some refactorings on marking menus for refactoring was the major reason that forced the developer to use a combination of marking menus and linear menus. While using marking menus for refactoring, the developer modified the menus in response to the criticisms made by interviewees the usability evaluation (Section VI). Three new styles for the menus are shown in Figure 5. C. Threats to Validity During this evaluation, marking menus were the focus of the development activities as well as the subject of the evaluation. This may threaten the validity of the results in three ways. First, the participating developer knew he was working on a research project with the goal of studying marking menus; this may have biased his opinions about marking menus. Second, during the project, the developer needed to test his changes to marking menus by using the menus themselves, which meant that he likely used marking menus more often than would an average developer. Third, knowing the code behind marking menus might make the developer blind to their defects and the difficulties that a user who is not also a developer of marking menus would face. VIII. F URTHER D IRECTIONS Previous work has shown improved speed and accuracy of marking menus compared to linear menus. These results, along with the experiments described in this paper, suggest that programmers should be able to use marking menus to initiate refactoring tools efficiently. However, to make marking menus ready for “prime time” we need to alleviate one of the major disadvantages of using our mapping with marking menus: some refactorings do not appear on the menu. One way to do this would be to allow the user to click on the center of the marking menu to reveal a nested marking menu, or a linear menu, that contains refactorings that do not have a spatial mapping. Another way would be to use hierarchical marking menus [12]. Each of these designs has usability tradeoffs, and we plan on investigating these tradeoffs in the future.

ACKNOWLEDGMENT For their advice and guidance, we thank Barry Anderson, Sergio Antoy, Margaret Burnett, Rob DeLine, Anthony Hornof, Mark Jones, Chuan-kai Lin, Ralph London, Karyn Moffatt, Gail Murphy, David Novick, Susan Palmiter, and our anonymous reviewers. Thanks to the Interaction Design Reading Group at UBC for their insightful comments. We also thank the participants in our experiment, and the National Science Foundation for partially funding this research under grant CCF-0520346. R EFERENCES

Fig. 5.

Three different flavors of marking menus

We would like to investigate how gestures can be used for other purposes both inside and outside of the domain of software development. For example, we imagine that gestures may work well for program navigation across a call or inheritance hierarchy. Mappings similar to ours may also be effective in other domains where system interaction is well-structured. For example, we can envision an analogous mapping for graphical design systems, where the up–down and more–less metaphor is systematic, such as moving objects up and down layers, increasing or decreasing the intensities of transformations (e.g., transparency, blurring, hue), and increasing or decreasing magnitudes (e.g., text size, stroke weight, rotation). IX. C ONCLUSION This paper introduces a novel mapping from gestures to refactorings and reports results that suggest that programmers can infer that mapping. This result suggests that gestural initiation of refactoring tools will help the right tool come quickly to hand when needed and otherwise fade into the background: our objective is for the code, not the tool, to be the focus of the programmer’s attention.

[1] M. Fowler, Refactoring: Improving the Design of Existing Code. Boston, MA, USA: Addison-Wesley Longman Publishing Co., 1999. [2] E. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor, and how we know it,” in ICSE ’09: Proceedings of the 2009 IEEE 31st International Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2009, pp. 287–297. [3] Z. Xing and E. Stroulia, “Refactoring practice: How it is and how it should be supported — an Eclipse case study,” in ICSM ’06: Proceedings of the 22nd IEEE International Conference on Software Maintenance. Washington, DC, USA: IEEE Computer Society, 2006, pp. 458–468. [4] C. Parnin, C. G¨org, and O. Nnadi, “A catalogue of lightweight visualizations to support code smell inspection,” in SoftVis ’08: Proceedings of the 4th ACM Symposium on Software Visualization. New York, NY, USA: ACM, 2008, pp. 77–86. [5] E. Murphy-Hill and A. P. Black, “Breaking the barriers to successful refactoring: observations and tools for extract method,” in ICSE ’08: Proceedings of the 30th International Conference on Software Engineering. New York, NY, USA: ACM, 2008, pp. 421–430. [6] A. O’Connor, M. Shonle, and W. Griswold, “Star diagram with automated refactorings for eclipse,” in Proceedings of the 2005 OOPSLA Workshop on Eclipse Technology eXchange. New York, NY, USA: ACM, 2005, pp. 16–20. [7] E. Murphy-Hill and A. P. Black, “Refactoring tools: Fitness for purpose,” IEEE Software, vol. 25, no. 5, September-October 2008. [8] J. Callahan, D. Hopkins, M. Weiser, and B. Shneiderman, “An empirical comparison of pie vs. linear menus,” in CHI ’88: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York, NY, USA: ACM, 1988, pp. 95–100. [9] T. Grossman, P. Dragicevic, and R. Balakrishnan, “Strategies for accelerating on-line learning of hotkeys,” in CHI ’07: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York, NY, USA: ACM, 2007, pp. 1591–1600. [10] G. C. Murphy, M. Kersten, and L. Findlater, “How are Java software developers using the Eclipse IDE?” IEEE Software, vol. 23, no. 4, pp. 76–83, 2006. [11] J. I. Hong and J. A. Landay, “SATIN: A toolkit for informal ink-based applications,” in ACM SIGGRAPH Courses, 2006, pp. 63–72. [12] G. Kurtenbach and W. Buxton, “The limits of expert performance using hierarchic marking menus,” in CHI ’93: Proceedings of the INTERACT ’93 and CHI ’93 Conference on Human Factors in Computing Systems. New York, NY, USA: ACM, 1993, pp. 482–487. [13] M. Burnett and H. Gottfried, “Graphical definitions: Expanding spreadsheet languages through direct manipulation and gestures,” ACM Transactions on Computer-Human Interaction, vol. 5, no. 1, pp. 1–33, 1998. [14] D. E. Kieras and S. Bovair, “The role of a mental model in learning to operate a device,” Cognitive Science: A Multidisciplinary Journal of Artificial Intelligence, Psychology and Language, vol. 8, no. 3, pp. 255– 273, 1984. [15] J. O. Wobbrock, H. H. Aung, B. Rothrock, and B. A. Myers, “Maximizing the guessability of symbolic input,” in CHI ’05 extended abstracts on Human factors in computing systems, ser. CHI EA ’05. New York, NY, USA: ACM, 2005, pp. 1869–1872. [Online]. Available: http://doi.acm.org/10.1145/1056808.1057043 [16] I. S. MacKenzie and S. X. Zhang, “The immediate usability of graffiti,” in Proceedings of the conference on Graphics interface ’97. Toronto, Ont., Canada, Canada: Canadian Information Processing Society, 1997, pp. 129–137. [Online]. Available: http://portal.acm.org/citation.cfm?id= 266774.266792