Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.

We describe extensions to the Excel spreadsheet that integrate userdefined functions into the spreadsheet grid, rather than treating them as a "bolt-on". Our first objective was to bring the benefits of additional programming language features to a system that is often not recognised as a programming language. Second, in a project involving the evolution of a well-established language, compatibility with previous versions is a major issue, and maintaining this compatibility was our second objective. Third and most important, the commercial success of spreadsheets is largely due to the fact that many people find them more usable than programming languages for programming-like tasks. Thus, our third objective (with resulting constraints) was to maintain this usability advantage.

This paper presents work conducted towards the development of an effective software engineering-based methodology for integrity control in the process of spreadsheet development. Various approaches and concepts within the discipline of software engineering are investigated. The proposed methodology consists of a set of coherent stages incorporating relevant software engineering techniques and principles. The framework for spreadsheet quality control is mainly aimed at addressing the widespread problem of spreadsheet errors. This paper elaborately discusses the application of relevant software engineering techniques and principles in the construction of spreadsheet models, accompanied and supported by appropriate examples. The principles and techniques of tree-based formula representation, unique definition of spreadsheet elements and separation of data and operations, are among the main features explored..

End-user programmers, because they are human, make mistakes. However, past research has not considered how visual end-user debugging devices could be designed to ameliorate the effects of mistakes. This paper empirically examines oracle mistakes—mistakes users make about which values are right and which are wrong—to reveal differences in how different types of oracle mistakes impact the quality of visual feedback about bugs. We then consider the implications of these empirical results for designers of end-user software engineering environments. 1.

End-user programmers are writing an unprecedented number of programs, due in large part to the significant effort put forth to bring programming power to end users. Unfortunately, this effort has not been supplemented by a comparable effort to increase the correctness of these often faulty programs. To address this need, we have been working towards bringing fault localization techniques to end users. In order to understand how end users are affected by and interact with such techniques, we conducted a think-aloud study, examining the interactive, human-centric ties between end-user debugging and a fault localization technique. Our results provide insights into the contributions such techniques can make to an interactive end-user debugging process. 1.

End-user programmers are writing an unprecedented number of programs, primarily using languages and environments that incorporate a number of interactive and visual programming techniques. To help these users debug these programs, we have developed an entirely visual, interactive approach to fault localization. This paper presents the approach. We also present the results of a think-aloud study that examined the interactive, human-centric issues that arise in end-user debugging using a fault localization strategy. Our results provide insights into the contributions such strategies can make to the end-user debugging process.

Spreadsheets are a common tool in end-user programming. But even while important decisions are based on spreadsheet computations, spreadsheets are poorly documented software and the differences between simple on-shot computations and large, long-living sheets are not well understood. Like other software, production spreadsheets are subject to repeated maintenance cycles. Consequently, as with conventional software, short maintenance cycles and poor documentation tend to decrease their quality. We introduce an approach to help maintainers understand the structure of large spreadsheets as well as to zoom into certain parts of the spreadsheet. To cope with large sheets, our approach features two levels of abstraction: logical areas and semantic classes. These abstractions are based on different degrees of relatedness of cells according to the formulas they contain.

Emerging research has sought to bring effective debugging devices to end-user programmers. This research has largely focused on how well such devices bring genuine “functional ” rewards to end users. However, emerging models of programming behavior indicate that another, often ignored, type of reward—perceivable rewards—can play an equally vital role in how well debugging devices serve end users. Using an empirically evaluated fault localization device, this paper investigates the impact such perceivable rewards can have on end-user debugging. Our results indicate that perceivable rewards alone can significantly improve the effectiveness and understanding of end users performing debugging tasks. 1.

Although researchers have developed several ways to reason about the location of faults in spreadsheets, no single form of reasoning is without limitations. Multiple types of errors can appear in spreadsheets, and various fault localization techniques differ in the kinds of errors that they are effective in locating. In this paper, we report empirical results from an emerging system that attempts to improve fault localization for end-user programmers by sharing the results of the reasoning systems found in WYSIWYT and UCheck. By evaluating the visual feedback from each fault localization system, we shed light on where these different forms of reasoning and combinations of them complement — and contradict — one another, and which heuristics can be used to generate the best advice from a combination of these systems. 1.

Most programs today are written not by professional software developers, but by people with expertise in other domains working towards goals for which they need computational support. For example, a teacher might write a grading spreadsheet to save time grading, or an interaction designer might use an interface builder to test some user interface design ideas. Although these end-user programmers may not have the same goals as professional developers, they do face many of the same software engineering challenges, including understanding their requirements, as well as making decisions about design, reuse, integration, testing, and debugging. This article summarizes and classifies research on these activities, defining the area of End-User Software Engineering (EUSE) and related terminology. The article then discusses empirical research about end-user software engineering activities and the technologies designed to support them. The article also addresses several crosscutting issues in the design of EUSE tools, including the roles of risk, reward, and domain complexity, and self-efficacy