An empirical study of fault localization for end-user programmers End users develop more software than any other group of programmers, using software authoring devices such as e-mail filtering editors, by-demonstration macro builders, and spreadsheet environments. Despite this, there has been little research on finding ways to help these programmers with the dependability of their software. We have been addressing this problem in several ways, one of which includes supporting end-user debugging activities through fault localization techniques. This paper presents the results of an empirical study conducted in an end-user programming environment to examine the impact of two separate factors in fault localization techniques that affect technique effectiveness. Our results shed new insights into fault localization techniques for end-user programmers and the factors that affect them, with significant implications for the evaluation of those techniques. A quiet paradigm shift is occurring in the world of software. Not long ago, most software was developed by "professional" program- * Work performed at Oregon State University, Corvallis, OR, USA.. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. mers. Today, however, end users write far more software than professional programmers: it is estimated that, in 2005 in the United States alone, 55 million end users, compared to only 2.75 million professional programmers [8] , will be creating software such as multimedia simulations, dynamic web pages, e-mail filtering rules, and spreadsheets. Do these programmers have adequate support? Evidence suggests that they do not. Boehm and Basili observe that 40-50% of the software created by end users contains non-trivial faults [9] . These faults can be serious, in some cases costing millions of dollars [14, 20, 24] .. A problem for the software engineering community, then, is to provide end users with better support for their software development activities. For example, end users, like professional programmers, need strategies for improving the dependability of their software, such as testing and anomaly detection methodologies to help them detect failures, and fault localization techniques to help them find the causes of failures. The latter is our focus in this paper.. Software engineering researchers have invested considerable effort into bringing fault localization techniques to professional programmers (e.g., [2, 10, 13, 15, 17, 23, 31] ), and similar efforts, directed at the needs of end users, could be worthwhile. However, significant differences exist between professional and enduser software development, and these differences have ramifications for any such efforts.. First, end users rarely have knowledge of software engineering methodologies, and are unlikely to take the time to acquire it. Traditional fault localization techniques often assume that their users have at least some knowledge of software engineering in order to properly employ the technique or understand its feedback. (As research [7, 12] explains, understanding is critical to trust, which in turn is critical to users actually believing a system's output and acting upon it.) Such techniques may be unsuitable for end users.. Second, end-user programming environments are usually modeless and interactive: users incrementally experiment with their software and see how the results work out after each change. Fault localization techniques that rely on batch processing (e.g., [2] ) are inconsistent or even incompatible with these types of environments.. Third, end users do not usually possess organized test suites, so large amounts of testing-derived data are rarely available for use in end-user environments. Complicating the situation is the interactive nature of end-user debugging: when end users observe a failure they often begin debugging immediately -not after running several tests -at which time the system may have little information with which to provide feedback. Thus, a fault localization tech-nique that requires large amounts of data (e.g., [15] ) may be inappropriate for end users.. Fourth, evidence shows that end users often make mistakes when performing interactive testing and debugging tasks [27] . (Professional programmers err too, of course, but their understanding of testing processes may render them less error-prone than end users.) Unfortunately, many fault localization techniques (e.g., [17] ) cannot operate effectively with such unreliable information.. We have been working to bring fault localization support to end users in ways that accommodate the foregoing considerations. Our previous work [26, 27] shows that this support can help end users find faults by leading them to employ more effective debugging strategies. However, our results also show that, at times, some fault localization techniques are not effective. Analysis of the cases in which the techniques are not effective suggests that there are actually two distinct factors involved in technique design that could be impacting their performance. The first factor -information base -refers to the type of information maintained by a technique and is commonly the subject of the research literature on fault localization. The second factor -mapping -refers to the way in which a technique maps the information into feedback, including both the calculation of this feedback using the information provided by the information base, and displaying the feedback in a manner that is compatible with the surrounding environment. Surprisingly, compared to the information base factor, this mapping factor has received scant attention in the research literature. Further, in our search of the literature we can find no previous work that has separated the impact of these two factors on a fault localization technique's effectiveness.. This work makes four contributions. First, we empirically investigate the impact of both information base and mapping on the effectiveness of fault localization techniques. Our results indicate that each factor significantly impacts effectiveness; thus, both must be considered when developing fault localization techniques. Second, we add to the end-user software engineering literature by providing empirical data on three information bases and three mappings that can be used in techniques for end-user programmers. Third, we provide insights into the way in which interactive fault localization effectiveness should be measured -insights that have implications for future empirical evaluations of end-user fault localization techniques. Fourth, we add to the growing body of evidence that end users make mistakes when performing interactive testing and debugging tasks, which has implications for the types of techniques that may be suitable for end-user programmers. Despite the growing number of end-user programmers, to date, relatively little research has sought to address the dependability issues that arise in end-user software. We are working on ways to bring software engineering methodologies to bear upon this problem, focusing in this paper on fault localization for end-user programmers.. In this paper we have considered two factors that make up fault localization techniques -information base and mapping -and investigated their impact on effectiveness. The work makes four primary contributions.. First, we describe two factors that affect fault localization techniques, and provide empirical data indicating that each factor significantly impacts the effectiveness of techniques. Two immediate implications are the need to separately (1) design and (2) evaluate each factor. While it may make intuitive sense that each factor would play a role in technique effectiveness, to date, no studies have explicitly teased the two factors apart and empirically confirmed that each indeed does have a significant role in effectiveness.. Second, we provide data on three particular information bases and three mappings for fault localization techniques, which serves to address the lack of empirical data concerning fault localization support for end users. In doing so, we found that the inexpensive, non-traditional I-NC information base performed particularly well. This surprising result makes I-NC especially advantageous in end-user programming given the importance of responsiveness in these highly interactive environments.. Third, we show why traditional measures for fault localization effectiveness, which are taken at the points of maximal system reasoning potential, are unsuitable in evaluating effectiveness in interactive environments, and we present a set of measures that is instead taken at user feedback points. This type of measurement is critical when measuring interactive debugging devices, which are common in end-user programming environments, to ensure that important feedback is not omitted.. Fourth, our results corroborate the growing body of evidence that end users make an alarming number of mistakes when performing interactive testing and debugging tasks; in our experiment, 74% of the debugging sessions were performed in the context of at least one incorrect testing decision. Such evidence suggests that some fault localization techniques, which assume that all testing information is correct, may not be suitable for end users.. All four of the above findings run counter to much of the fault localization research aimed at professional programmers. In fact, our results indicate that a number of traditional assumptions in that prior work are not appropriate for fault localization in end-user software environments. The results regarding RQ1 showed that information base often made a significant difference in effectiveness. This result is consistent with other fault localization research. We also found that the information bases' differences in effectiveness were most pronounced at the end of debugging sessions, most likely due to the increased testing information available, allowing the techniques a greater opportunity to differentiate themselves from each other. That effectiveness, however, did not always improve as debugging sessions progressed -in the case of Gradebook, all nine combinations of information base and mapping became worse. This may relate to the mistakes the users made in their testing, a point we will return to shortly.. Recall that one goal of this study was to provide empirical data on three particular information bases and mappings. Although all of our information bases generally performed well, a surprise was the performance of I-NC. One reason this is surprising is that I-NC is the information base least like those employed in many traditional techniques, which tend to use counts of failed and passed tests (as does I-TC) or dicing-like approaches (as does I-BL). A second reason is that I-NC is the least computationally expensive of the information bases we compared.. Turning to RQ2, the role of the mapping factor was quite pronounced. While we found two significant differences at the 0.05 level and one difference at the 0.01 level in RQ1, our investigation of RQ2 yielded one significant difference at the 0.05 level, and nine differences at the 0.01 level. These significant differences occurred despite only small distinctions among the three mappings (i.e., the number of fault likelihood values, and the "initial" value).. This result has two implications. First, great care should be exercised in selecting mappings for fault localization techniques. To our knowledge, no previous work has provided empirical evidence to support this finding. Second, because both factors are important, evaluating each factor separately is important in order to obtain acFirst X-mark I-TC I-BL I-NC Gradebk (n = 13) curate information regarding a technique. Otherwise, in attempting to improve a technique's ability to pinpoint faults, researchers could actually weaken their technique's effectiveness by manipulating a factor that was already working well and overlooking the real culprit. One result from RQ3 was that the end-user test suites contained many mistakes, corroborating previous findings [27] . The effects of these mistakes were far-reaching too -although they numbered just under 25% of the tests, they affected 74% of the debugging sessions. This result underlines the seriousness with which this issue should be regarded, especially since it runs contrary to a common assumption in prior research: that all testing has been reliable. Most fault localization research has been based on program slicing -a survey of which is provided by Tip [30] -and dicing [17] techniques. Our fault localization techniques draw from information gleaned via slicing, and make use of that information using heuristics inspired by dicing.. There has been a great deal of work on fault localization strategies for professional programmers (e.g., [2, 10, 13, 15, 17, 23, 31] ). For example, Agrawal et al. [2] present a technique, implemented as χslice, for locating faults using execution traces from tests. This technique is based on displaying dices of the program relative to one failing test and a set of passing tests. Jones et al. [15] describe a similar approach implemented as TARANTULA. Unlike χslice, TARANTULA uses information from all passing and failing tests, coloring statements based on the likelihood that each statement is faulty according to its ratio of failing to passing tests. Using a faulty "run" and a larger number of correct runs, Renieris and Reiss's technique [23] compares the faulty run with the correct run that most resembles it, and reports "suspicious" areas of the program. Two ways in which our approach differs from these are that our methods (1) are targeted at end users, and (2) are interactive and incremental at the granularity of revising fault likelihood estimations in real time after each single program edit.. Pan and Spafford [19] present a family of 20 fault localization heuristics based on program statements exercised by passing and failing tests, three of which directly relate to the mappings of our techniques.. A little work aimed specifically at aiding end users with fault localization is emerging. For example, Ayalew and Mittermeir [6] present a method of "fault tracing" for spreadsheets that uses "interval testing" and slicing. Woodstein [32] is a web interface agent that assists e-commerce debugging. Ko and Myers [16] present a type of fault localization via the Whyline, an "interrogative debugging" technique. Our approach differs from the first strategy by allowing users to interactively improve feedback by providing the system with additional information, and from all these strategies through the incorporation of a robustness feature [26, 27] .. There is other work that can help end users find faults. S2 [28] provides a visual auditing feature in Excel 7.0. Work is emerging to automatically detect certain kinds of errors, such as errors in spreadsheet units [1, 5] and types [3] . There has also been work to help end users detect failures, such as statistical outlier finding [18] and anomaly detection [22] . Finally, the assertions approach [33] in Forms/3 automatically detects failures in spreadsheet cells, and has been shown empirically to help end users.

O O O O B I O B O O O O O B O O O B O O O B O O O O O B O O O O O B B O O O O O O B O O O O B O O O O O O O B O O O O O O O O O O O O O O B B O O B I O O B O O O O O O O O O O B O O O O O O O O O O O B I O O B O O O O O O O O B I O O B O O O O O B O O O O O O B O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O B I O O B O O O O O O O O O O O O O B B O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B I O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O B B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B O O O O O O O O O O B I O O O O O O B B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B I O O O O O O O O O O O O O B B I O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O B O O O O O B O O O O O O O O O O B B O O O O O O O B O O O O O O O O O O B O B I O B O O O B O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B B I O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O B I O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O B I O B B B O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B I O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O


The Astrophysics Simulation Collaboratory Portal: a Framework for Effective Distributed Research We describe the Astrophysics Simulation Collaboratory (ASC) portal, a collaborative environment in which distributed projects can perform research. The ASC project seeks to provide a web-based problem solving framework for the astrophysics community to harness computational Grids. To facilitate collaboration amongst distributed researchers within a virtual organization, the ASC Portal supplies specialized tools for the management of large-scale numerical simulations and the resources on which they are performed. The ASC Virtual Organization uses the Cactus framework for studying numerical relativity and astrophysics phenomena. We describe the architecture of the ASC Portal and present its components with emphasis on elements related to the Cactus framework. In a variety of scientific disciplines, complex research problems are being investigated by geographically distributed collaborations. Computational grids are emerging as a distributed computing infrastructure that will allow these collaborations to seamlessly access computational resources and perform largescale numerical simulations. The Cactus framework (www.cactuscode.org) and Computational Toolkit (7), a scientific code developed at the Albert Einstein Institute and used throughout the world, is a step towards providing a common computational environment in the astrophysics community. Cactus was initially designed for solving the equations governing Einstein's Theory of General Relativity, but is presently used in various scientific disciplines such as bioinformatics and atmospheric sciences. Cactus enables research into a large variety of physical problems and is portable across all computer architectures. It has emerged as an important tool for groups of researchers performing largescale numerical simulations. While numerous scientific groups are benefiting from the features of Cactus, effective use of this code on diverse and distributed computational resources would benefit from a connection between the scientists, their simulations and emerging Grid services (1; 5) . Such a connection is provided by the simulation management framework of the Astrophysics Simulation Collaboratory (ASC) portal (www.ascportal.org).. The ASC Portal is intended to deliver a collaborative simulation management framework for generic applications, with the development driven by a particular community of astrophysicists, numerical relativists and computational science researchers that use and develop their codes with Cactus. This community makes up a virtual organization (VO) (4) , denoted as the ASC Virtual Organization (ASC VO). End user involvement from this VO has been a crucial factor in providing a truly useful and appropriate working environment through the ASC Portal, both in terms of core functionalities and also in the design of the user interface. The ASC Portal codebase serves as a solid foundation for extensions to the next generation portlet and services frameworks, such as that being developed by the Portal Group of the GridLab project.. An important recent aspect of the ASC development is a collaboration between the ASC and the new European GridLab project (www.gridlab.org). The ASC project involves the Washington University Gravity Group, the University of Illinois at Urbana-Champaign/National Center for Supercomputing Applications, the University of Chicago/Argonne National Laboratory, Rutgers University, and the Albert Einstein Institute in Potsdam, Germany. The GridLab project is a European funded collaboration involving eight countries in Europe and three institutes in the US along with industrial partners Compaq and Sun. The ASC and GridLab projects both involve components aimed at solving the common problem of managing simulations on various super-computers across the world; the web portal technology is a key component of the solution to this problem. The GridLab project is extending the ASC technology to a wider community of researchers (10) .. The ASC Portal has prototyped and tested many different Grid and collaborative capabilities (11; 15) . This paper primarily focuses on those aspects concerned with simulation management that are important to the researchers in the ASC VO. Section 2 describes the basic architecture of the ASC Portal, Section 3 describes how computational resources are managed and accessed, Section 4 introduces the configuration tools that are provided for portal administrators, Section 5 illustrates how simulations are staged and monitored, Section 6 describes the ASC Portals role at SC2002 and Section 7 outlines future directions and plans following from this work. The potential of Grid computing is just beginning to be realized. In order to reach the next stage in the evolution of Grid computing, research projects like the ASC and GridLab, as well as the organizations that provide computational resources to application scientists, must cooperate more effectively towards building a solid Grid infrastructure and technologies for successfully administering and utilizing that infrastructure. Grid portals will begin to play a more prominent role because of their flexibility for providing user interfaces to Grid services such as GRAM. However, the next stage of Grid computing requires that more research communities start considering how the Grid can be effectively utilized to meet the ever growing resource needs of today's scientific applications. The ASC has taken part in this process by working closely with the research communities that are using Cactus to help drive the development of tools for utilizing the Grid. More importantly, we hope to make it easier for application scientists to acquire the resources they need and to build better tools for managing their applications on the Grid. We look forward to continuing our research and collaborating with others in this very exciting field.

O B I I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Program representations for testing wireless sensor network applications Because of the growing complexity of wireless sensor network applications (WSNs), traditional software development tools are being developed that are specifically designed for their special characteristics. However, testing tools have yet to be proposed. One problem in developing testing tools is the need for a program representation that expresses the execution behavior. Due to characteristics of WSN applications that use a concurrent, event-based execution model, a representation is challenging to develop. In this paper, we present novel representations for WSNs applications that express the execution behavior of event and tasks, the major components of a WSN application. Our representations include a task posting graph, an event graph and finally an application graph that expresses the relationships among events and tasks as well as both timing and environmental interrupts. These representations are the first step in developing testing tools for WSN applications. Based on the graphs, traditional and event-based coverage criteria can be evaluated. When combined with individual Control Flow Graphs(CFGs) of events and tasks, the graphs' paths can be used as a criterion for evaluating the completeness of the test cases. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Wireless sensor networks (WSNs) continue to expand in both the number of such networks and the size of the networks as the recognition of their importance increases and technology improves. They are used in many different applications, from monitoring and controlling aspects of the environment to managing safety critical events such as the braking system on a car. Indeed, scientists have forecasted that WSN applications will dominate the software market in the near future [3] .. As the demand and complexity of the applications increases and market forces become more competitive, developers of WSN applications are turning to traditional software development techniques. Thus, WSN applications are being implemented in high level languages such as Java and source level debuggers are being developed [13] . However, tools to systematically test WSN applications have yet to be developed.. Identifying software faults is one of the significant challenges in developing WSNs systems today. Due to resource limitations and the desire to develop more complex functionality, applications on WSNs often have a limited capacity to handle errors: the software crashes before being able to inform the user about the error. Moreover, as WSNs are mainly deployed in hard-to-reach locations, patching and fixing software after deployment is very costly. Therefore, testing tools for WSNs are critical components to help provide the reliability that is needed. Unfortunately, neither the WSN nor the software engineering research communities have applied systematic, structural software testing or regression testing tools and techniques to this domain. Current testing of WSN has depended on the use of ad-hoc methods using simulators and either simulated, profiled or randomly generated inputs from the environment [6, 10, 11] . However with this approach, the application is not being tested on the actual hardware or in the actual environment in which it will run. WSN applications are concurrent, event-driven systems which frequently interact with their environments through interrupts and events that happen at arbitrary times. Therefore, to analyze and test WSN applications, we need to be able to determine the impact of these interrupts on the code. Currently, there is no comprehensive set of testing tools, or a testing framework, that can be used to systematically test WSNs that takes into account the execution environment and its execution model.. An important component of a testing framework is a program representation that can model all possible execution behaviors of the software. Because of the novel characteris-tics of WSN applications, conventional representations such as CFGs or event graphs [9] cannot adequately model the execution behavior. Although there have been some efforts to construct representations for WSNs [4, 12] , they have been developed for a purpose other than testing and their models are not fine-grained enough to express the execution behavior at statement level; thus they cannot be employed for structural testing purposes.. Because WSN applications employ an event-based, concurrent execution model, challenges arise in the development of a detailed representation that can accurately express every program execution path. For instance, in tinyOS [1] , the most widely used operating system for WSNs, program execution is rooted in hardware interrupts caused by timers, sensors, and communication devices. Long running processes can be triggered in response to these interrupts by tasks that are placed in a single task queue. Execution order is tightly bound to the timing of interrupts, so that the sequencing of events cannot be determined using only source code. As a result, conventional representations, such as call graphs and CFGs, are helpful for extracting some information, but cannot be used to determine the order of execution of events and tasks and their relationships. The event graph that Memon proposed for representing a GUI [9] cannot represent the concurrency of WSNs. Hence, a new representation for WSNs, which does consider the functionality of the code as well as the possible behavior of events and interrupts that can occur on motes is necessary to facilitate the development of testing tools, and in particular the definition and evaluation of testing coverage criteria.. In this paper, we present a representation of an application executing on a mote of a WSN that expresses the execution order of events and tasks, and thus program paths. Our representation expresses (a) the time at which events are anticipated and (b) the order in which a certain event directly or indirectly posts its tasks to the system task queue. In particular, we present three representations: an event graph and a task posting graph, which together are used to form an application graph. The graph for an event expresses the order in which tasks are posted; the task posting graph represents the order in which tasks post other tasks and the application graph represents all of the events in an application. After integrating the CFG of event handlers, tasks and both timing and environmental interrupts, our application graph can be used to obtain all program execution paths, which can be used as a testing coverage criterion. Conventional code coverage criteria such as all-events coverage, all event sequence coverage and def-use can be naturally derived and checked.. It should be noted that our representation is for a single mote running in a network. Our representation expresses communication from other motes to the mote and the interrupts that can occur. We do not represent the entire network though, which is a part of our future work.. In the next section, we present a brief background of WSN applications. Then, challenges in developing representations for WSN applications are discussed in Section 3. Section 4 describes each of the three representations in detail. We then briefly discuss our implementation in Section 5. Section 6 addresses related work. We have completed the implementation of the above representations. The front end of the representation builder employs the parser and compiler of TinyDT [8] , an Eclipse plug-in for WSN development. From abstract syntax trees obtained from TinyDT, our tool constructs the CFGs and three graphs described above. Preliminary experimental results on the overhead have been produced and are promising. We are also developing an analysis to detect patterns in the configuration code of the application using our graphs to detect seeded errors.. As our representations provide detailed information about the application and its environment, they enable testing a WSN system within its environment in a number of ways.. For instance, a GApp describes all possible events in the application, including anticipated events that could occur during the execution path of other events and tasks. Analyzing anticipating edges in the GApp and their sets of interrupting points can determine a scenario demonstrating interactions between the application and the environment. Similarly, a GEvent contains ordering information of task posting units within a stand-alone event and analyzing the GEvent can guarantee code coverage of each event. Therefore, using these representations can help frame code coverage criteria at different levels and develop the analysis for determining the coverage needed. Possible criteria for WSNs are based on the GUI event coverage criteria [9] and propose all-event coverage, all static-path coverage as well as all possible sequence of events coverage. The all-event criterion ensures that each event is executed at least once during the testing. The all-static path criterion expresses that each path in the corresponding GEvent will be executed at least once. The sequence of events criterion is fulfilled when a particular sequence of events in the GApp is executed. Similar to the approach in [9] , we argue that instead of checking unlimited length sequences, shorter sequences are sufficient to detect errors in WSNs as is the case with GUIs.. Furthermore, a complete order of event handlers and tasks in an application can be integrated through their CFGs to form an inter-event CFG. The obtained inter-event CFG contains concrete program execution paths that can facilitate structural testing and static analysis technique. A test case can be developed by specifying a set of inputs leading to a given execution path in the inter-procedural CFG. For example, the path denoted by (*) in Figure 5 , which consist of init, start, Timer1.fired(), Timer2.fired(), task4, task3, task4, stop in that order, leads to the inter-event CFG with the following execution path {< l1 − l5 >, l8, < l10 − l11 >,< l20 − l22 >} (code is given in Figure 2 ). The path triggers the divided-by-zero exception in line l20 of the code and the test case associating with that path would reveal an existing bug of the program: variable numberOfRead has not been increased before variable readrate2 is calculated. Therefore, when used together with CFGs, GEvent and GApp can generate execution paths which lead to test cases and test oracles.. Beside testing, our graphs can also be used for other static analysis techniques. Being able to trace the impact of each post statement in the application within and beyond the border of functions, our GEvent and GPost can detect call patterns and configuration errors as well [14] . There have been a few research efforts to provide an intermediate representation for analyzing WSNs' applications for various purposes. One approach uses different types of automata to model a WSN application such as hybrid automata [4] and parallel interpreted automata [12] . Although this approach succeeds for simulation or model checking techniques such as life time analysis, automata are not finegrained enough to determine the behavior of each individual statement. Therefore, automata cannot be used for static analysis needed in testing. Another approach [2] discusses that recording every state of every single mote in the network because the number of nodes is tremendous. To solve this problem, Agha [2] proposes using statistic values as values for properties of a system. Again, this representation loses details of each individual mote; hence this representation cannot help static analysis which is the focus of our representation framework.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Evaluating

an

eye

tracking

interface

for

a

two-dimensional

sketch

editor

Throughout

the

history

of

CAD,

a

variety

of

interfaces

have

been

employed

with

the

aim

of

supporting

designers'

construction

and

manipulation

of

digital

models.

This

paper

explores

the

potential

of

eye

tracking

as

a

CAD

interface,

and

presents

a

prototype

that

uses

collected

gaze

data

to

support

shape

exploration

in

a

two-dimensional

vectorbased

sketch

editor.

The

eye

tracking

interface

uses

the

visual

interactions

of

users

to

identify

interpretations

of

constructed

shapes,

according

to

recognised

parts

identified

using

methods

from

shape

grammar

research.

It

can

therefore

be

argued

that

it

supports

construction

and

manipulation

of

shapes

according

to

user

intent.

The

prototype

has

been

evaluated

in

a

user

study

where

design

students

carried

out

controlled

shape

exploration

exercises

which

involved

interpretation

and

manipulation

of

shapes.

In

the

paper,

key

concepts

of

eye

tracking

methodology

are

introduced;

the

methods

used

to

implement

the

eye

tracking

interface

are

described;

and

the

user

study

and

its

outcomes

are

reported.

The

results

are

positive

and

indicate

the

potential

for

eye

tracking

as

an

interface

for

supporting

shape

exploration

in

CAD.•

Explores

the

potential

of

eye

tracking

as

an

interface

for

computer

aided-design•

Describes

methods

for

inferring

user

intent

with

respect

to

digital

shape

manipulation,

based

on

gaze

data

Presents

a

prototype

eye

tracking

interface

that

supports

dynamic

shape

interpretation

in

a

vector-based

sketch

editor

Reports

the

outcomes

of

a

user

study

that

evaluates

how

successful

the

eye

tracking

interface

is

at

inferring

users'

intent

with

respect

to

shape

manipulation

Computer-aided

design

(CAD)

systems

are

ubiquitous

in

modern

design

processes.

But,

despite

this,

it

has

been

noted

that

they

are

rarely

used

to

design,

and

are

instead

mostly

used

to

record

and

communicate

the

outcomes

of

design

activities

Pen

(cil)

and

paper

remain

the

media

of

choice

for

ideation

and

creative

design

For

example,

Robertson

and

Radcliff

report

the

outcomes

of

a

survey

that

questioned

CAD

users

concerning

the

impact

of

CAD

on

creative

problem

solving.

They

found

that

use

of

CAD

results

in

enhanced

visualisation

and

communication

but

also

an

increase

in

circumscribed

thinking

and

premature

fixation.

Indeed,

Lawson

and

Locke

argue

that

CAD

systems

are

not

capable

of

supporting

creative

design

because

their

development

has

placed

too

much

emphasis

on

graphical

representation

techniques,

and

not

enough

emphasis

on

exploring

how

processes

essential

to

creative

design

can

be

supported..

They

argue

that

central

to

creative

design

are

ambiguity,

uncertainty

and

parallel

lines

of

thought

and,

while

these

are

readily

supported

by

hand

drawing,

they

are

not

supported

by

computational

systems.

Similarly,

Hanna

and

Barber

argue

that

the

computerised

design

process

supported

by

CAD

systems

does

not

reflect

the

analysis-synthesisevaluation-presentation

structure

that

is

typically

expected

in

a

conventional

design

process.

They

found

that

although

CAD

presented

many

advantages

in

terms

of

simulation,

analysis

and

presentation,

it

also

resulted

in

a

modified

approach

to

designing.

Stacey

and

Eckert

suggest

that

CAD

systems

encourage

conservative

design

practice

because

they

make

it

easier

to

use

particular

design

elements,

standard

choices

and

default

parameter

values.

A

similar

argument

is

also

presented

by

Mitchell

who

notes

that

rather

than

CAD

systems

supporting

users'

creative

processes,

users

learn

to

adapt

their

design

practice

so

that

they

are

consistent

with

the

particular

CAD

systems

that

they

use,

and

this

is

often

evident

in

the

resulting

designs.

Specifically,

designers

have

to

learn

to

work

with

the

data

structures

on

which

CAD

systems

are

built,

the

operations

and

tools

that

the

systems

support,

and

the

interactions

afforded

by

their

user

interfaces..

Jenkins

explores

difficulties

that

arise

when

using

CAD

systems,

and

suggests

that

these

occur

as

a

necessary

consequence

of

the

wide

ranging

functionality

that

is

expected

of

such

systems.

It

is

proposed

that

difficulties

could

be

mitigated

via

efficient

documentation,

comprehensive

training

and

interoperability

between

different

systems..

While

these

are

practical

suggestions,

they

avoid

addressing

the

intrinsic

limitations

of

CAD

systems

as

tools

for

supporting

creative

design.

Indeed,

if

future

CAD

systems

are

to

realise

their

raison

d'etre

as

computational

aids

for

design,

then

their

fundamental

architecture

needs

to

be

reconsidered

so

that

they

support

the

processes

that

are

essential

to

creative

design.

Accordingly,

Sener

and

Wormald

report

a

study

that

sought

to

identify

how

CAD

systems

and

their

user

interfaces

could

be

re-imagined

so

that

they

can

support

creative

design.

They

identified

four

general

requirements

that

could

lead

to

CAD

systems

that

would

better

support

designers'

needs.

These

are:

bulk

form

creation;

control

of

form

creation;

ease

of

form

creation;

life-like

form

creation.

This

paper

is

concerned

with

the

third

of

these

requirements,

"ease

of

form

creation",

and

explores

the

potential

of

eye

tracking

as

an

interface

to

support

the

construction

and

manipulation

of

designed

shapes.

It

presents

a

prototype

interface

that

augments

traditional

mouse

and

keyboard

input.

It

uses

collected

gaze

data

to

support

shape

exploration

in

a

two-dimensional

vector-based

sketch

editor

by

considering

the

user's

attention

and

intention

as

they

computationally

manipulate

shapes..

Throughout

the

history

of

CAD,

a

variety

of

interfaces

have

been

employed

with

the

aim

of

supporting

designers'

interactions

with

design

models,

including

interfaces

that

respond

to

traditional

sketching,

e.g.

Sutherland

or

natural

actions

in

virtual

worlds,

e.g.

Israel

et

al.

or

interfaces

that

take

advantage

of

manipulation

of

physical

artefacts

and

tactile

feedback

e.g.

Abdelmohsen

and

Do

.This

paper

reports

research

that

investigates

the

use

of

eye

tracking

as

an

interface

for

CAD,

specifically

for

a

two-dimensional

sketch

editor.

Eye

tracking

technologies

can

be

used

to

provide

insight

into

visual

interactions

between

a

viewer

and

a

scene,

via

recorded

eye

movements.

Such

data

can

identify

the

point

of

gaze

of

the

viewer,

which

in

turn

is

indicative

of

how

the

viewer

is

attending

to

a

scene

As

an

interface

for

CAD,

eye

trackers

have

the

potential

to

support

visual

interaction

between

the

designer

and

the

design

representation.

They

can

act

as

an

unobtrusive

and

natural

interface

that

responds

to

the

intentions

of

the

designer,

as

exhibited

by

visual

attention.

Potentially,

they

can

realise

the

ideal

drawing

editor

tool

which,

in

the

words

of

Saund

and

Moran

"would

be

able

to

read

the

user's

mind

(his

visual

system

in

particular)

and

synchronize

with

whatever

image

entities

the

user

happens

to

perceive

as

significant"

(p.

In

this

way,

eye

tracking

could

substantially

reduce

the

cognitive

overhead

needed

for

designers

to

interface

with

CAD

systems

and

with

design

representations.

This

paper

presents

a

prototype

interface

that

is

a

first

imagining

of

the

potential

applications

of

eye

tracking

as

an

interface

for

CAD.

Specifically,

the

prototype

addresses

the

problem

of

computational

shape

interpretation

with

an

aim

to

support

design

generation

and

exploration

in

CAD

systems..

Shape

interpretation

is

central

to

the

processes

of

design

generation

and

exploration,

and

as

such

has

been

linked

to

creativity

For

example,

in

many

creative

professions,

including

industrial

design

and

architecture,

conceptual

design

involves

the

creation,

exploration,

and

development

of

design

shape

alternatives.

These

processes

are

typically

supported

using

freehand

sketching

because

the

ambiguity

of

sketches

enhances

the

cognitive

processes

of

shape

interpretation

which

are

essential

in

effective

shape

exploration

and

development

Commercially

available

CAD

systems

offer

poor

support

for

shape

interpretation

because

the

data

structures

on

which

they

are

built

assume

that

a

given

shape

has

a

unique

interpretation

As

such,

they

do

not

support

the

flexible

interaction

that

designers

need

during

design

exploration

for

conceptual

design,

and

instead

are

typically

used

to

record

the

outcomes

of

these

processes.

For

example,

an

architect

exploring

the

shape

illustrated

in

Figure

as

part

of

a

floor

plan

for

a

building,

may

interpret

the

shape

in

different

ways,

each

with

its

own

conceptual

meaning

In

Figure

To

construct

the

design

using

CAD

the

architect

must

decide

which

of

these

interpretations

to

work

with

and,

once

the

model

has

been

constructed,

changes

in

interpretation

will

not

be

readily

supported.

For

example,

if

the

architect

constructs

a

model

according

to

the

interpretation

in

Figure

then

the

shape

will

be

structured

according

to

triangular

parts;

but,

if

the

model

is

constructed

according

to

the

interpretation

in

Figure

then

it

will

be

structured

according

to

K-shaped

parts.

In

neither

scenario

would

the

CAD

model

support

exploration

of

the

shape

because

the

structure

of

the

shape

will

be

fixed

according

to

the

parts

initially

identified..

The

research

presented

in

this

paper

explores

how

an

eye

tracking

interface

could

support

multiple

interpretations

of

shape

in

CAD.

It

has

resulted

in

a

prototype

that

uses

eye

tracking

data

to

identify

users'

interpretations

of

constructed

shapes,

based

on

recognised

parts

which

are

identified

using

methods

from

shape

grammar

research.

It

therefore

supports

manipulation

of

the

shape

according

to

user

intention.

For

example,

the

shape

in

Figure

could

be

manipulated

as

both

triangles

and

Ks,

depending

on

the

changing

intention

of

the

architect,

as

recognised

by

the

eye

tracking

interface.

The

prototype

interface

recognises

the

differences

in

user

intention

according

to

the

parts

they

are

attending

to,

and

restructures

shapes

so

that

the

parts

of

interest

are

available

for

manipulation.

The

prototype

has

been

evaluated

in

a

user

study,

in

which

design

students

were

tasked

with

carrying

out

controlled

shape

exploration

exercises

which

involved

interpretation

and

manipulation

of

shapes.

The

data

collected

was

analysed

to

determine

how

successful

the

eye

tracking

interface

is

at

inferring

user

intent

with

respect

to

shape

manipulation.

The

results

are

positive

and

indicate

the

potential

for

eye

tracking

as

an

interface

for

CAD..

The

next

section

presents

an

overview

of

the

motivation

for

the

research,

namely

supporting

shape

interpretation

in

CAD.

Section

introduces

key

concepts

of

eye

tracking

methodology

and

a

brief

review

of

its

application

as

an

interface

for

computational

systems.

In

Section

the

eye

tracking

interface

is

introduced,

with

detailed

descriptions

of

the

methods

used

in

its

implementation.

Section

reports

evaluation

of

the

interface,

including

a

description

of

the

user

study

and

a

discussion

of

the

results.

Finally,

in

Section

the

paper

ends

with

a

brief

discussion

exploring

the

potential

benefits

of

eye

tracking

as

an

interface

for

future

CAD

systems.

The

aim

of

the

user

study

was

to

determine

how

successful

the

eye

tracking

interface

is

at

inferring

users'

interpretations

of

constructed

shapes

according

to

recognised

parts..

To

this

end,

the

participants'

on-screen

interactions

with

the

shapes

were

analysed

to

identify

when

lines

were

selected

using

mouse

clicks

and,

in

response

to

a

mouse

click,

whether

the

interface

correctly

identified

the

current

interpretation

of

a

shape

or

not.

If

the

correct

interpretation

was

not

identified

then

the

collected

data

was

analysed

to

identify

why.

In

particular,

the

gaze

data

was

analysed

to

identify

where

the

user

was

looking

at

the

moment

a

line

was

selected.

Also

the

shapes

were

analysed

according

to

their

potential

parts

and

the

COGs

of

those

parts,

as

illustrated

in

Figure

These

four

examples

illustrate

a

range

of

possible

outcomes,

including

shapes

with

various

numbers

of

parts

and

parts

with

COGs

that

overlap

by

different

amounts.

Figure

illustrates

Step

of

the

first

exercise,

where

the

square

is

to

be

recognised

and

manipulated.

The

shape

has

three

potential

parts,

two

rectangles

and

a

square,

and

the

COGs

of

these

parts

touch

but

do

not

overlap.

Figure

illustrates

Step

of

the

first

exercise,

where

the

L-shape

is

to

be

recognised

and

manipulated.

The

shape

has

four

potential

parts,

two

rectangles,

a

square

and

an

L-shape.

The

COG

of

the

L-shape

is

external

to

the

shape

and

overlaps

the

COGs

of

the

rectangles

by

approximately

pixels,

but

does

not

overlap

the

COG

of

the

square.

Figure

illustrates

Step

of

the

first

exercise,

where

the

square

is

to

be

recognised

and

manipulated.

The

shape

has

only

two

potential

parts,

a

square

and

an

L-shape,

and

the

COGs

of

these

overlap

considerably,

by

approximately

pixels.

Gaze

is

an

implicit

indicator

of

attention

and

intention,

and

eye

tracking

has

significant

potential

as

an

additional

interface

that

augments

traditional

mouse

and

keyboard

by

responding

to

users'

visual

interactions.

With

respect

to

design,

eye

tracking

can

be

used

to

substantially

reduce

the

cognitive

overhead

needed

for

designers

to

interface

with

CAD

systems

by

inferring

their

intended

manipulations

of

design

models.

The

prototype

eye

tracking

interface

presented

here

is

a

first

imagining

of

the

possibilities,

and

explores

how

gaze

data

can

be

used

to

infer

users'

interpretation

of

ambiguous

shapes

during

shape

exploration.

Evaluation

of

the

interface

was

positive,

and

throughout

the

user

study

it

was

successfully

able

to

respond

to

participants'

visual

intentions,

allowing

manipulation

of

recognised

parts

of

shapes.

The

participants

also

commented

that

the

interface

could

be

a

useful

addition

to

CAD,

supporting

faster

and

easier

form

creation..

Shape

interpretation

is

an

essential

process

in

design

exploration,

but

is

not

readily

supported

in

commercial

CAD

systems.

As

a

result,

Robertson

and

Radcliffe

note

that

use

of

CAD

can

result

in

premature

fixation

because

of

a

reluctance

to

incorporate

ideas

that

will

result

in

too

many

changes

to

a

constructed

design

model

or

its

underlying

structure.

Fundamentally,

this

issue

manifests

because

digital

design

models

impose

a

distance

between

designers

and

the

representations

that

they

work

with,

a

distance

which

does

not

arise

with

physical

design

media,

such

as

sketches

In

sketches,

there

is

no

distinction

between

the

visual

shape

and

its

representation.

The

shape

is

the

shape,

and

this

means

that

visual

interpretations

can

immediately

be

incorporated

into

shape

exploration.

Conversely,

when

designers

work

with

computational

tools

such

as

CAD,

the

visual

shape

is

a

rendition

of

formal

data

structures

which

have

a

single

interpretation.

The

shape

is

not

the

shape

but

is

a

visualisation

of

a

particular

data

structure

-the

ambiguity

and

richness

of

the

visual

shape

are

not

accounted

for.

The

eye

tracking

interface

presented

here

tries

to

address

this

problem

by

supporting

dynamic

reinterpretation

of

shapes

according

to

the

visual

structure

that

is

recognised

by

the

designer

from

moment

to

moment.

As

such

it

supports

explorative

processes,

with

the

designer

free

to

interpret

shapes

according

to

dynamically

changing

structure,

thereby

encouraging

what

Schön

and

Wiggins

refer

to

as

the

reflective

conversation

between

the

designer

and

the

design

representation.

Also,

because

the

interface

supports

multiple

interpretations

of

shape

it

affords

ambiguity,

uncertainty

and

parallel

lines

of

thought,

which

Lawson

and

Locke

argue

are

central

to

creative

design.

Eye

tracking

can

respond

to

visual

interaction

with

digital

design

models

and

compliment

design

processes,

by

literally

supporting

the

seeing-moving-seeing

process

of

creative

shape

exploration.

This

suggests

that

an

eye-tracking

interface

could

be

used

to

provide

more

appropriate

computational

support

during

conceptual

design

and

could

result

in

a

computerised

design

process

that

encourages

creative

design

practice.

However

these

claims

have

not

been

tested,

but

instead

are

an

area

for

investigation

in

future

user

studies..

The

prototype

is

only

one

of

many

potential

applications

for

eye

tracking

as

an

interface

for

CAD.

As

identified

by

the

participants

in

the

user

study,

eye

tracking

can

serve

as

a

useful,

implicit,

method

for

selection

and

could,

for

example,

be

used

to

simplify

navigation

of

the

complex

menu

systems

that

are

common

in

CAD

systems.

Or,

as

discussed

in

the

previous

section,

it

could

also

be

useful

in

collaborative

design,

to

make

the

intentions

of

members

of

design

teams

apparent

to

colleagues.

Also,

with

respect

to

shape,

gaze

could

be

a

useful

guide

for

localizing

mouse-based

input

on

digital

models,

enabling

more

efficient

manipulation.

The

rapidly

diminishing

cost

of

eye

tracking

technology,

commercially

and

as

a

result

of

open

hardware

projects

such

as

openEyes

mean

that

eye

tracking

interfaces

are

becoming

a

realistic

possibility

for

future

human-computer

interaction.

This

gives

rise

to

exciting

possibilities

for

designers,

enabling

them

to

control

their

computational

tools

using

methods

previously

not

possible.

O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O