The ready availability of online source-code examples has fundamentally changed programming practices. However, current search tools are not designed to assist with programming tasks and are wholly separate from editing tools. This paper proposes that embedding a task-specific search engine in the development environment can significantly reduce the cost of finding information and thus enable programmers to write better code more easily. This paper describes the design, implementation, and evaluation of Blueprint, a Web search interface integrated into the Adobe Flex Builder development environment that helps users locate example code. Blueprint automatically augments queries with code context, presents a code-centric view of search results, embeds the search experience into the editor, and retains a link between copied code and its source. A comparative laboratory study found that Blueprint enables participants to write significantly better code and find example code significantly faster than with a standard Web browser. Analysis of three months of usage logs with 2,024 users suggests that task-specific search interfaces can significantly change how and when people search the Web.

Mechanical Turk provides an on-demand source of human computation. This provides a tremendous opportunity to explore algorithms which incorporate human computation as a function call. However, various systems challenges make this difficult in practice, and most uses of Mechanical Turk post large numbers of independent tasks. TurKit is a toolkit for prototyping and exploring truly algorithmic human computation, while maintaining a straight-forward imperative programming style. We present the crash-andrerun programming model that makes TurKit possible, along with a variety of applications for human computation algorithms. We also present a couple case studies of TurKit used for real experiments outside our lab. ACM Classification: H5.2 [Information interfaces and

Intelligibility can help expose the inner workings and inputs of context-aware applications that tend to be opaque to users due to their implicit sensing and actions. However, users may not be interested in all the information that the applications can produce. Using scenarios of four real-world applications that span the design space of context-aware computing, we conducted two experiments to discover what information users are interested in. In the first experiment, we elicit types of information demands that users have and under what moderating circumstances they have them. In the second experiment, we verify the findings by soliciting users about which types they would want to know and establish whether receiving such information would satisfy them. We discuss why users demand certain types of information, and provide design implications on how to provide different intelligibility types to make context-aware applications intelligible and acceptable to users.

Testing a GUI’s visual behavior typically requires human testers to interact with the GUI and to observe whether the expected results of interaction are presented. This paper presents a new approach to GUI testing using computer vision for testers to automate their tasks. Testers can write a visual test script that uses images to specify which GUI components to interact with and what visual feedback to be observed. Testers can also generate visual test scripts by demonstration. By recording both input events and screen images, it is possible to extract the images of components interacted with and the visual feedback seen by the demonstrator, and generate a visual test script automatically. We show that a variety of GUI behavior can be tested using this approach. Also, we show how this approach can facilitate good testing practices such as unit testing, regression testing, and test-driven development. Author Keywords GUI testing, GUI automation, test by demonstration

Observations of developers indicate that developers try to answer a variety of questions by searching across control flow paths through a program for statements matching search criteria. We believe that tools that better support this activity can help developers answer these questions more easily, quickly, and accurately.

Instructive example code is a central part of programming. Web search enables programmers to quickly locate relevant examples. However, existing code editors offer little support for helping users interactively explore examples. This paper proposes that effective use of examples hinges on the programmer's ability to quickly identify a small number of relevant lines interleaved among a larger body of boilerplate code. This insight is manifest in Rehearse, a code editing environment with two unique features: First, Rehearse links program execution to source code by highlighting each line of code as it is executed. This enables programmers to quickly determine which lines of code are involved in producing a particular interaction. Second, after a programmer has found a single line applicable to her task, Rehearse automatically identifies other lines that are also likely to be relevant. In a controlled experiment, participants using visualization and highlighting adapted example code significantly faster than those using an identical editor without these features. Author Keywords Example-centric programming

Software developers understanding and exploring code spend much of their time asking questions and searching for answers. Yet little has been known about the questions devel-‐ opers ask, the strategies used to answer them, and the challenges developers face. Through interviews, surveys, and observations, a series of 7 studies were conducted that begin to address this gap, contributing a better understanding of developers ’ tools, practices, prob-‐ lems, questions, and strategies, and a model of how developers reconstruct design decisions from code. A design process is described for using studies of developers ’ work to design more useful tools for developers. These studies reveal that reachability questions are a central part of understanding and ex-‐ ploring code. A reachability question is a search along paths through code. Developers ask reachability questions when reasoning about causality, ordering, type membership, repeti-‐ tion, and choice. For example, to debug a deadlock, a developer searched downstream for calls acquiring resources to reconstruct how and why resources were acquired. Existing tools make these questions challenging to answer by forcing developers to guess which

Debugging is notoriously difficult and extremely time consuming. Researchers have therefore invested a considerable amount of effort in developing automated techniques and tools for supporting various debugging tasks. Although potentially useful, most of these techniques have yet to demonstrate their practical effectiveness. One common limitation of existing approaches, for instance, is their reliance on a set of strong assumptions on how developers behave when debugging (e.g., the fact that examining a faulty statement in isolation is enough for a developer to understand and fix the corresponding bug). In more general terms, most existing techniques just focus on selecting subsets of potentially faulty statements and ranking them according to some criterion. By doing so, they ignore the fact that understanding the root cause of a failure typically involves complex activities, such as navigating program dependencies and rerunning the program with different inputs. The overall goal of this research is to investigate how developers use and benefit from automated debugging tools through a set of human studies. As a first step in this direction, we perform a preliminary study on a set of developers by providing them with an automated debugging tool and two tasks to be performed with and without the tool. Our results provide initial evidence that several assumptions made by automated debugging techniques do not hold in practice. Through an analysis of the results, we also provide insights on potential directions for future work in the area of automated debugging.

Amazon’s Mechanical Turk provides a programmatically accessible micro-task market, allowing a program to hire human workers. This has opened the door to a rich field of research in human computation where programs orchestrate the efforts of humans to help solve problems. This thesis explores challenges that programmers face in this space: both technical challenges like managing high-latency, as well as psychological challenges like designing effective interfaces for human workers. We offer tools and experiments to overcome these challenges in an effort to help future researchers better understand and harness the power of human computation. The main tool this thesis offers is the crash-and-rerun programming model for managing high-latency tasks on MTurk, along with the TurKit toolkit which implements crash-and-rerun. TurKit provides a straightforward imperative programming environment where MTurk is abstracted as a function call. Based on our experience using TurKit, we propose a simple model of human computation algorithms involving creation and decision tasks. These tasks suggest two natural workflows: iterative

Interactive run-time visualization of object-oriented software requires views of the current state as well as the execution history. However, as software complexity grows, runtime visualizations become unwieldy and their effectiveness quickly degrades, necessitating techniques to scale the them gracefully without compromising their meaning. The main contribution of this paper is showing that declarative queries and (run-time) object/sequence diagrams work in a symbiotic manner to achieve scalable visualizations: queries help the user to focus on specific regions of the diagrams, while the diagrams provide a framework for reporting the answers to queries. We propose two broad classes of techniques to achieve compact sequence diagrams: folding operations, for nested calls and also a sequence of calls; and filtering operations, to remove unnecessary or irrelevant calls relative to a debugging task. We introduce a refinement of the sequence diagram to account for missing calls, and regular-expression labels for compacted execution sequences. Together, these techniques have proven to be effective, and they have been implemented and tested as part of the dynamic analysis tool,