10. End-User Development

by Margaret M. Burnett and Christopher Scaffidi

Computer users have rapidly increased in both number and diversity (Scaffidi et al 2005). They include managers, accountants, engineers, home makers, teachers, scientists, health care workers, insurance adjusters, salesmen, and administrative assistants. Many of these people work on tasks that rapidly vary on a yearly, monthly, or even daily basis. Consequently, their software needs are diverse, complex, and frequently changing. Professional software developers cannot directly meet all of these needs because of their limited domain knowledge and because their development processes are too slow.

End-user development (EUD) helps to solve this problem. EUD is "a set of methods, techniques and tools that allow users of software systems, who are acting as non-professional software developers, at some point to create, modify, or extend a software artifact" (Lieberman et al 2006). In particular, EUD enables end users to design or customize the user interface and functionality of software. This is valuable because end users know their own context and needs better than anybody else, and they often have real-time awareness of shifts in their respective domains. Through EUD, end users can tune software to fit their requirements more closely than would be possible without EUD. Moreover, because end users outnumber professional software developers by a factor of 30-to-1 (Figure 1), EUD "scales out" software development activities by enabling a much larger pool of people to participate.

However, EUD is inherently different from traditional software development, and trying to support EUD by simply mimicking traditional approaches is often insufficient to produce successful results. End users usually do not have training in professionals' programming languages, formal development processes, or modeling and diagramming notations. Moreover, end users often lack the time or motivation to learn these traditional techniques, since end users usually write code in order to achieve a short- or medium-term goal rather than to create a durable software asset that will produce a continuing revenue stream. Consequently, supporting EUD requires providing appropriate tools, social structures, and development processes that are highly usable, quickly learned, and easily integrated into domain practice.

EUD overlaps with two similar concepts, end-user programming and end-user software engineering. End-user programming (EUP) enables end users to create their own programs (Ko et al 2011). This subset of EUD is the most mature from a research and practice perspective, so we focus a later section of this article on that portion of EUD. The difference between EUP and EUD is that EUD methods, techniques, and tools span the entire software development lifecycle, including modifying and extending software, not just the "create" phase.

The other related concept overlapping with EUD is end-user software engineering (EUSE). EUSE is a relatively new subset of EUD that began about a decade ago. Its emphasis is on the quality of the software end users create, modify, or extend; thus its research focuses on methods, techniques, and tools that promote the quality of such software. This area has arisen because of the ample evidence that the programs end users create are filled with expensive errors (Panko 1998; Burnett 2010; Ko et al 2011). We therefore focus on the EUSE subset of EUD in a later section of this article.

Projected population sizes for American workplaces in 2012, based on federal data (note that categories are not mutually exclusive)

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.1: Projected population sizes for American workplaces in 2012, based on federal data (note that categories are not mutually exclusive)

Courtesy of Rikke Friis Dam and Mads Soegaard. Copyright: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported).

End-User-Development - Introduction to End-User Development

Courtesy of Rikke Friis Dam and Mads Soegaard. Copyright: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported).

End-User-Development - Business Value - Applicability in Industry

End-User-Development - Gender Differences in End-User Development

Courtesy of Rikke Friis Dam and Mads Soegaard. Copyright: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported).

End-User-Development - Future Directions

10.1 The birth of EUD

Prior to the 1980's, most computing occurred on mainframes controlled by professional developers in information systems departments. End users had little influence over the form and function of software running on a mainframe, which they generally viewed through simple terminal windows and controlled with simple textual commands (Figure 2). Information systems departments rarely had enough staff time to design and implement all of the software enhancements requested by users (Brancheau and Wetherbe 1987).

EUD grew out of a confluence of innovations embodied in the machines known as "microcomputers" (a term eventually replaced with "personal computer"). First, these machines were inexpensive enough that organizations could afford to provide each user with a machine. Having their own machines made it viable for users to modify ("tailor") the machine's software settings without impacting the computing environment of other users. Second, microcomputers had sufficient hardware power so that users could compile (or interpret) new code in languages such as Basic. This in turn provided infrastructure for end users to create new applications. Third, microcomputers soon came to include innovative new features such as the mouse and powerful graphics cards, which accelerated usability advances such as graphical user interfaces (GUIs) and direct manipulation; these advances, in turn, opened up the possibility of novel programming tools specifically designed to meet the needs of users.

Spreadsheets were the first major EUD programming environment made possible by these innovations (Bricklin et al 1979), beginning with VisiCalc (Figure 3), then continuing with Lotus 1-2-3 and Excel. Although users of spreadsheet systems may not think of themselves as "doing programming," spreadsheet systems are programming environments because their formulas are first-order functional programs (Jones et al 2003). In such programs, the formulas can refer to input "variables" (cell names) and the results of the formulas are computed output values. The availability of spreadsheet software was a major factor in spurring early demand for microcomputers (Ichbiah 1993). Newer technologies such as the web and mobile computing have since opened up increasingly diverse and powerful opportunities for end users to create and tailor software.

Terminal interface presenting a fixed menu, where users type a number to indicate a menu selection Courtesy of e53. Copyright: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Figure 10.2: Terminal interface presenting a fixed menu, where users type a number to indicate a menu selection

Visicalc circa 1980

Courtesy of Dave Winer. Copyright: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Figure 10.3: Visicalc circa 1980

10.2 Tailoring

Tailoring is any "activity to modify a computer application within its context of use" (Won et al 2006). Tailoring can be a simple or complex activity. At each increased level of complexity, users have more ability to redesign the interaction and functionality of an application. At the most basic level, tailoring encompasses specifying parameters to an existing application in a way that changes its behavior at a high level of granularity. For example, a person might use a graphical user interface to indicate which features of a spreadsheet editor should be visible (Figure 4) or how a word processor should respond to various inputs (Figure 5). Once tailoring begins to involve creating full-fledged programs in order to extend the functionality of an application, the activity seamlessly encompasses end-user programming (below). For instance, a user might create scripts called "macros" that manipulate the buttons, text, or other graphical user interface elements within an application. Such macros can extend applications with new functionality or make existing functionality more usable (Figure 6). Researchers have proposed a variety of component-based frameworks that can be used to implement easily-tailored applications (Won et al 2006). For instance, the "Selection" object referenced in Figure 6 is actually a component representing the region of text that is currently highlighted by the user in the word processor. The component-based framework makes it possible for an interpreter to manipulate the highlighted text in response to macros' instructions.

Screen in Microsoft Excel for tailoring which features should be activate and visible

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.4: Screen in Microsoft Excel for tailoring which features should be activate and visible

Screen in Microsoft Word for tailoring how the application handles clicks on hyperlinks, copy/paste commands, and other kinds of user input

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.5: Screen in Microsoft Word for tailoring how the application handles clicks on hyperlinks, copy/paste commands, and other kinds of user input

Using a code editor to create three Microsoft Word text-manipulation macros that are linked (through a separate screen) to keyboard shortcuts; for example, the first macro has a single instruction ind

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.6: Using a code editor to create three Microsoft Word text-manipulation macros that are linked (through a separate screen) to keyboard shortcuts; for example, the first macro has a single instruction indicating that the application should convert whatever is on the system clipboard into a textual representation and then paste it into the document.

10.3 End-user programming (EUP)

End-user programming (EUP) is defined as "programming to achieve the result of a program, rather than the program itself" (Ko et al 2011). In EUP, the developer's goal is to actually use the program; this contrasts with professional programming, where the goal is to create a program for other people to use, often in exchange for monetary compensation. The programs created through EUP can be extensions of existing applications (as in Figure 6, above), or they can be new applications that run separately from existing applications. End users can perform EUP through a wide range of interaction styles (Nardi 1993), as we discuss next.

10.3.1 Programming using visual attributes

In environments supporting the visual programming style of interaction, at least some of a program's semantics is expressed through the visual layout of the program. For example, the grid-like arrangement of cells in a spreadsheet carries a certain semantics; specifically, cells that are vertically or horizontally aligned with one another are part of a composite object defined solely based on the visual layout of cells (e.g, the range B:B references all of the second column in Microsoft Excel). In a visual language, semantics can hypothetically be encoded in many attributes of a visual representation, such as position, color, size, and intersection with other shapes. As another example, Figure 7 shows a visual language where each instruction is a colored block whose color indicates what kind of instruction it is and whose shape indicates what other blocks can appear next or before this block. Figure 8 shows a third example of a visual language. As with many visual languages, the LabView programming tool allows users to drag and drop these shapes using the GUI. Another common way of interacting through a visual language is with a form (Figure 9). In such an interface, the user cannot freely drag and drop shapes but rather must make selections from pre-defined fields.

Visual interface for editing the three scripts for the ball in a 'pong' game animation. The programmer lays out sprites on the right; clicking a sprite brings up its scripts for editing in t

Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.7: Visual interface for editing the three scripts for the ball in a 'pong' game animation. The programmer lays out sprites on the right; clicking a sprite brings up its scripts for editing in the center. Primitives can be dragged-and-dropped from the toolbox at left. (Resnick et al 2009)

LabVIEW programming language for creating circuit simulations and other programs. Each box represents a computational component, while lines indicate flow of data (similar to wires carrying signals)

Courtesy of Sam Shearman. Copyright: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Figure 10.8: LabVIEW programming language for creating circuit simulations and other programs. Each box represents a computational component, while lines indicate flow of data (similar to wires carrying signals)

User interface in Microsoft Word for creating a style, which is a set of formatting instructions that will be applied to multiple labeled regions in the document

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.9: User interface in Microsoft Word for creating a style, which is a set of formatting instructions that will be applied to multiple labeled regions in the document

10.3.2 Programming-by-demonstration (PBD)

Programming-by-demonstration (PBD), sometimes called programming-by-example, is a programming technique whereby the user demonstrates the new program's logic, from which the programming environment infers a program representing that logic. Some PBD systems are able to deductively infer the entire program, while others deduce what they can and ask the user for help for the rest (Cypher 1993). PBD-based tools are available for creating animations (Repenning and Perrone 2000; McDaniel and Myers 1999) and many other kinds of programs (Cypher 1993). One problem with PBD has been representing the final program in a form useful to the user (Cypher 1993; Yang et al 1997), to enable the end-user developer to review, test, and debug the program. Thus, PBD is often used in combination with visual or textual languages.

For example, a user could create a Microsoft Word macro (like those shown in Figure 6) through PBD. The user would first click a button or menu item indicating that the application should start watching the user's actions. The user would then use the GUI to demonstrate the desired behavior for the macro; for example, the user might use a series of menu items and dialog windows to paste the system clipboard as text. The user would click the "stop recording" button so that Microsoft Word stops watching the user's actions. At that point, the application would generate a macro containing VBScript instructions for repeating the demonstrated actions. The user could give the macro a keyboard shortcut and a name, if desired, in order to simplify running or editing it later. In addition, the user might want to edit the macro's instructions so that they perform a task slightly different than the one that was demonstrated, particularly if the user wants the macro to complete a task that is impossible with the existing GUI (rather than merely hard-to-use). In this way, the user could add completely new functionality to an application, with PBD serving to provide a starting point for another approach to programming.

10.3.3 Programming-by-specification

Programming-by-specification is an interaction style where the user describes a desired program, and a tool then generates the program for the user. As in PBD, the generated program can then be represented to facilitate review and customization by the user. For example, Liu and Lieberman (2005) implemented a system that accepts a specification in natural language and generates a corresponding program written in Python. A key limitation of this approach, as with inference-based PBD approaches, is that it is difficult for a user to predict what program will be generated from any particular input. Another is that, as with PBD, representation can be a difficult issue. For example, if the input interaction is done with English but the output is a traditional programming language such as Python, the end user must be fluent in both languages. Another limitation is that the programming tool can often correctly process only a limited range of inputs. This restricts the usefulness of the tool and also makes it difficult for a user to predict whether (and how) some particular input will be "understood" by the tool (e.g, could the Liu and Lieberman tool mentioned above generate games, and if so, what kinds of games?) In order to make the bounds of a tool's input language more obvious to users, some systems provide a forms-based visual interface (Figure 10) rather than a textual interface, thereby restricting users' specifications to only those that can actually be handled by the tool (Scaffidi et al 2009).

Visual specification of what a phone number looks like; from this specification, the tool generates code that can check whether a particular string matches the specification (Scaffidi 2009)

Courtesy of Christopher Scaffidi. Copyright status: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.

Figure 10.10: Visual specification of what a phone number looks like; from this specification, the tool generates code that can check whether a particular string matches the specification (Scaffidi 2009)

10.3.4 Programming with text

Programming with text is the most traditional interaction technique for programming, and for a time, some believed that this style of programming would not be appropriate for EUP. However, as the previous examples have shown, most programming environments that support other interaction styles also include text to some extent. As another example, Figure 11 shows the textual language that the CoScripter tool uses to represent a web macro, which is a script that directs a web browser to navigate the web and manipulate web sites in a particular way (Leshed et al 2008); such a web macro is typically created through PBD and then customized in textual form as needed. Despite the proliferation of alternative interaction styles, text remains widely used because of its conciseness and effectiveness for communicating abstract concepts.

Using the CoScripter programming tool to edit a web macro that tells the browser to look up information on the American Airlines website. The macro's execution has been paused at the second instr

Copyright © Scaffidi, Bogart, Burnett, Cypher, Myers and Shaw 2010. All Rights Reserved. Reproduced with permission. See section "Exceptions" in the copyright terms below.

Figure 10.11: Using the CoScripter programming tool to edit a web macro that tells the browser to look up information on the American Airlines website. The macro's execution has been paused at the second instruction (left), which instructs CoScripter to highlight Flight Number on the web page (right) and fill it in from the user's 'Personal Database' configuration file (lower left). Scaffidi et al 2010.

10.4 End-user software engineering (EUSE)

End-user software engineering (EUSE) is defined as "end-user programming involving systematic and disciplined activities that address software quality issues" (Ko et al 2011). Attention to quality is important for EUP because poorly-written software can cause data loss, security breaches, financial loss, or even physical harm, even when the software is created by end-user developers. The software qualities relevant to EUSE are the same as those of interest to professional developers who sell their products. These qualities include reliability, performance, maintainability, reusability, privacy, and security. Some qualities, such as maintainability and reusability, only become apparent after a program has been written and in operation for some time. Thus, EUSE combines the goal of EUP, which focuses on enabling end users to create software, with the concern for quality of that software across its entire lifecycle. This lifecycle includes requirements, design, verification, debugging and code reuse (in addition to actual implementation, which has already been described above in the context of EUP tools).

10.4.1 Requirements and design

Requirements describe what a program should do, and design refers to determining how a program should do it. For example, a requirement might be that a program should be able to sort a list of mailing addresses, and its design might detail the sorting algorithm to be used.

Examples of requirements (goals) in EUD include personalizing the way that an application or computer behaves, automating time-consuming tasks, performing computations that are hard to do accurately by hand, or communicating information (Ko et al 2011; Blackwell 2004; Blackwell 2006; Rosson et al 2002). Getting these requirements right is a critical aspect from the perspective of EUSE, because of its emphasis on quality. Professional developers are expected to investigate, document, and refine requirements before they start to design or code an application. For example, they might try to identify inconsistencies in requirements by applying one of several painstaking techniques (e.g, stakeholder review or formal modeling). In contrast, end users often live in their domain every day and know it very well, so they often already have an idea about what the requirements, and do not do any extra work to arrive at them, document them, or check them.

However, sometimes end users do not know the requirements in advance and do not aspire to a "design" per se; they may expect these matters to be clarified as the program's implementation evolves (Costabile et al 2006; Fischer and Giaccardi 2006; Morch and Mehandjiev 2000; Segal 2007). (Professional developers sometimes do not know the requirements in advance either, but they are expected to take steps to deal with that situation, such as employing an iterative method that fills in requirements as prototypes evolve, rather than entirely omitting the concept and moving on.) In this case, end-user developers may jump directly into coding without taking the time to document their requirements or look for inconsistencies (Rosson et al 2010). A related situation is that, because of the tight coupling of EUD to a domain, external shifts in the domain can cause evolution in requirements; for example, changes to accounting rules might require a financial analyst to compute different data, which might in turn cause modifications to an existing spreadsheet. Due to its highly iterative nature, EUD requirements-refinement has been likened to a form of highly agile programming (Lieberman et al 2006).

Thus, end-user programmers' requirements tend to be emergent and tightly intertwined with design. Given this, many design approaches that have been targeted toward end-user programmers aim to support evolutionary or exploratory approaches. DENIM is one example (a sketching system for designing web site), which allows users to leave parts of the design in a rough and ambiguous state until that section is better understood (Newman et al 2003). The process of exploratory design can also be assisted by a design critic, which is a software feature that can review a user's design and give suggestions for improvement (Figure 12). For example, Janus is a tool with a visual language enabling users to design floor plans for homes (Fischer et al 1990). It contains a design critic with an extensible expert system that can identify suboptimal combinations of objects in floor plans and suggest revisions to fix those design problems. It also displays a rationale for each suggestion, so that the user can reason about whether and how to apply the advice.

Another approach is for less experienced end-user developers to seek a review from more experienced peers. By identifying short lists of best practices and providing appropriate tools, researchers have tried to make this review as efficient as possible so that it can be applied without greatly slowing the EUD lifecycle (Ronen et al 1989; Powell and Baker 2003; Rosson et al 2008). Such an approach seems most likely to be successful in an organizational setting, where end-user developers have peers that they can call upon (and where the management hierarchy can be used, if appropriate, to mandate and enforce design reviews). Another variant of this idea that has emerged recently is meta-design, a team-of-equals collaborative approach in which professional developers handle some of the design task, and end-user domain experts handle different aspects (Fischer and Giaccardi 2006; Costabile et al 2006).

Researchers have also begun to explore approaches for adapting existing software engineering design techniques to the EUD context. For example, design patterns might be relevant but need adaptation to meet the needs of end-user developers (Diaz et al 2008). Another relatively new approach is the combination of design/specifications with verification capabilities, as with the Topes system discussed earlier (Scaffidi 2009).

Overview of the design critic process, where the user specifies a proposed design/solution, which the design critic feature (right) reviews based on encoded domain knowledge and a model of the user�

Copyright © Fischer, Lemke, Mastaglio and Morch, 1990. All Rights Reserved. Reproduced with permission. See section "Exceptions" in the copyright terms below.

Figure 10.12: Overview of the design critic process, where the user specifies a proposed design/solution, which the design critic feature (right) reviews based on encoded domain knowledge and a model of the user's goal (Fischer et al 1990)

10.4.2 Verification and validation

Verification and/or validation (V&V) cover activities attempting to make sure that a program does what it is supposed to do. Testing is the most common approach for V&V (even among professional developers). One of the first works supporting V&V in EUD was to help users evaluate whether their programs contained bugs by encouraging end users to test strategically. Perhaps the most developed end-user testing approach is "What You See Is What You Test" (WYSIWYT), which guides users through the process of systematically testing spreadsheets (Fisher et al 2006). WYSIWYT employs a "Surprise-Explain-Reward" strategy (Wilson et al 2003), in which surprises such as colored borders attract users' attention to areas of the spreadsheet that need testing, and tool tips explain the colors' meaning and the potential reward in using the testing devices (Figure 13). Behind the scenes, WYSIWYT uses a formal test adequacy criterion to reason about elements of the formulas that have been covered by tests so far.

An alternative approach for finding errors in programs is for the programming tool to automatically look for errors on the basis of types, dimensions, or units (Erwig and Burnett 2002; Abraham and Erwig 2007; Coblenz et al 2005; Chambers and Erwig 2009). This approach can be regarded as specific kinds of assertions. For example, one system associates types with spreadsheet cells (based on the placement of labels at the top of columns and at the left end of rows) and specifies how these types propagate through the spreadsheet (Figure 14). If two cells with different types are combined, then their type is generalized if an applicable type is available (e.g.: "3 apples + 3 oranges = 6 fruit"), or else an error message is shown.

WYSIWYT approach, where checkmarks indicate testedness, question marks indicate that a cell needs testing, and colored borders indicate correctness

Copyright © Burnett, Sheretof, Ren and Rothermel, 2002. All Rights Reserved. Reproduced with permission. See section "Exceptions" in the copyright terms below.

Figure 10.13: WYSIWYT approach, where checkmarks indicate testedness, question marks indicate that a cell needs testing, and colored borders indicate correctness

Using the UCheck feature to test for unit errors in a spreadsheet

Copyright © Abraham and Erwig, 2007. All Rights Reserved. Reproduced with permission. See section "Exceptions" in the copyright terms below.

Figure 10.14: Using the UCheck feature to test for unit errors in a spreadsheet

10.4.3 Debugging

After a programming error is detected, the next step is to remove it by debugging. Some of the debugging techniques used by professional developers have been adapted for use in EUP tools. In addition to inserting "print" statements that display the value of variables as a program executes, end user developers can step through instructions one at a time, watching for incorrect operations (Leshed et al 2008). Assertions represent another important traditional technique that has been adapted for use in EUP: a user can insert a conditional into the code, and the program will call attention to that point if the conditional evaluates to false at execution (Burnett et al 2003; Koesnandar et al. 2008; Scaffidi 2009).

Several EUP tools provide tight integration between testing and debugging. For example, assertions can be inserted proactively when a program is created, in order to perform automatic tests and initiation of debugging if an assertion fails. For instance, when a web macro is initially created, it might perform properly; however, upon later execution, invalid outputs might arise either because of a bug in the macro itself or because of changes in the structure and content of websites (the macro inputs). An assertion can catch such errors that arise, halt execution, and bring them to the user's attention to prevent the macro from running awry (Figure 15). Several other EUP tools that support testing techniques, such as those mentioned above, also leverage test results to facilitate debugging. For example, once incorrect spreadsheet cells have been identified through testing, dependencies can be traced back automatically to identify and highlight the formulas that are most likely to have caused those erroneous outputs (Ayalew and Mittermeir 2003; Burnett et al 2003).

A new class of debugging tools based on question asking has recently emerged and has proven effective in EUSE. The first tool to take this approach was the Whyline, which was prototyped for the Alice programming environment that enables users to program animations (Ko and Myers 2004). Users execute their program, and when they see a behavior they have a question about, they press a "Why" button. This brings up a menu of "why did" and "why didn't" questions, organized according to the structure of the visible 3D objects manipulated by the program. Once the user selects a question, the system analyzes the program's execution history and generates an answer explaining the error in terms of the events that occurred during execution. The Whyline approach has also been applied to debugging other kinds of programs (e.g, Ko and Myers 2008; Kulesza et al 2009).

Popup window asking user to indicate whether and how a Robofox web macro should be modified due to a violated assertion

Copyright © Koesnandar, Elbaum, Rothermel, Hochstein, Scaffidi, and Stolee. All Rights Reserved. Reproduced with permission. See section "Exceptions" in the copyright terms below.

Figure 10.15: Popup window asking user to indicate whether and how a Robofox web macro should be modified due to a violated assertion

10.4.4 Reuse

After code is written, reuse can speed the creation of later programs. Supporting reuse of end-user programs is challenging because end-user developers rarely have the opportunity or training required to design highly reusable programs. Another challenge is that end-user developers can make mistakes when creating programs or other files for tailoring applications, and reusing these can propagate errors across an organization (Mackay 1990). Therefore, even though systems such as repositories or file servers can make it easy for end-user developers to post programs for others to reuse, it can be extremely difficult and time-consuming for other developers to evaluate the reusability of these programs. To help reduce the difficulty of reusing programs, models of what makes end-user programs reusable are now being developed in the hopes of helping users to search repositories for reusable programs related to the user's particular interests (Scaffidi et al 2010). Outside of repositories, other work has begun to explore how to help users to extract reusable pieces (Oney and Myers 2009).

10.5 The future and implications of EUD

As users continue to grow in number and diversity, EUD is likely to play an increasingly central role in shaping software to meet the broad, varied, rapidly changing needs of the world. Along the way, further research is needed to help end-user developers create and adapt new kinds of programs in new kinds of ways. For example, as the Web 2.0 era unfolds, researchers are investigating new ways of helping users to automate the synthesis of data from multiple websites through web macros and mashups (Scaffidi et al 2008; Zang et al 2008). Another ongoing shift is the rapidly-increasing role of small mobile computers, such as smart phones; work has recently begun on enabling end users to create "apps" or other programs for these devices (Google App Inventor 2010).

With the continually broadening scope and power of end-user programming, substantial additional attention to quality will become increasingly crucial. In particular, as users continue to interact with larger numbers of anonymous peers (e.g, through social networks or "app stores"), their code may become more visible to others and therefore more susceptible to attack. Moreover, since users can now share their programs with any person on the web, many more people could be affected by an error in an end-user programmer's code. Therefore, further research is needed to help end-user developers produce software with stronger guarantees of security and privacy, without interfering with the lightweight, iterative nature of the EUD lifecycle. Moreover, as massive amounts of data become accessible through the web to users, they may need better support for designing and implementing programs with increased scalability. It will be necessary for researchers to develop new approaches, since approaches used by professional software developers, such as buffer-overrun analysis for security or Big-O analysis for performance, may be irrelevant or too complex for the needs of end-user programmers.

More broadly, EUD's continuing development as a social phenomenon has important implications for the relationship between end users and professional software developers (Fischer and Giaccardi 2006, Costabile et al 2006). The rise of EUD to date enables end users to respond to professional developers' backlog of software work, and to the reality that professional software developers are not likely to understand and plan for every user requirement when developing software. With continuing advances in EUSE, end users will not only be able to create a variety of software on their own, but they will also to be able to assess and improve that software's quality on their own—so that they know to what extent to rely upon it, and what to do to increase the software's quality if needed. As a result, the fit between software's form and individual users' needs might be closer than has been possible before, vastly increasing the usefulness of software in peoples' lives.

10.6 Where to learn more

10.6.1 Books

  • Lieberman, H., Paterno, F., and Wulf, V. (eds.) 2006. End User Development, Springer.
  • Cypher, A, and Halbert, D. (eds.) 1993. Watch What I Do: Programming By Demonstration, The MIT Press.
  • Lieberman, H. (ed.) 2001. Your Wish Is My Command: Programming By Example, Morgan Kaufmann.

10.6.2 Relevant conferences and workshops

10.6.2.1 CHI - Human Factors in Computing Systems

20112010200920082007200620052004200320022001200019991998199719961995199419931992199119901989198819871986198519831982

10.6.2.2 VL-HCC - Symposium on Visual Languages and Human Centric Computing

20082007200720062005200420032002200120001999199819971996199519941993199219911990

10.6.2.3 ISEUD - International Symposium on End User Development

2009

10.6.3 Relevant organizations

10.7 References

Abraham, Robin and Erwig, Martin (2007): UCheck: A spreadsheet type checker for end users. In J. Vis. Lang. Comput., 18 (1) pp. 71-95

Abraham, Robin and Erwig, Martin (2004): Header and Unit Inference for Spreadsheets Through Spatial Analyses. In: VL-HCC 2004 - IEEE Symposium on Visual Languages and Human-Centric Computing 26-29 September, 2004, Rome, Italy. pp. 165-172

Ayalew, Yirsaw and Mittermeir, Roland (2008): Spreadsheet Debugging. In CoRR, 0

Ayalew, Y. and Mittermeir, R. (2003): Spreadsheet debugging. In: Proceedings of the European Spreadsheet Risks Interest Group 2003. pp. 22-23

Blackwell, Alan (2006): Gender in Domestic Programming: from Bricolage to Séances d'Essayage. In: CHI2006 Workshop on End User Software Engineering 2006.

Blackwell, Alan (2004): End-user developers at home. In Communications of the ACM, 47 (9) pp. 65-66

Boal, Augusto (1992): Games for Actors and Non-Actors. Routledge

Boehner, Kirsten, dePaula, Rogerio, Dourish, Paul and Sengers, Phoebe (2007): How emotion is made and measured. In International Journal of Human-Computer Studies, 65 (4) pp. 275-291

Boehner, Kirsten, dePaula, Rogerio, Dourish, Paul and Sengers, Phoebe (2005): Affect: from information to interaction. In: Bertelsen, Olav W., Bouvin, Niels Olof, Krogh, Peter Gall and Kyng, Morten (eds.) Proceedings of the 4th Decennial Conference on Critical Computing 2005 August 20-24, 2005, Aarhus, Denmark. pp. 59-68

Brancheau, James C. and Wetherbe, James C. (1987): Key Issues in Information Systems Management. In MIS Quarterly, 11 (1) pp. 23-45

Brancheau, James C., Janz, Brian D. and Wetherbe, James C. (1996): Key Issues in Information Systems Management: 1994-95 SIM Delphi Results. In MIS Quarterly, 20 (2) pp. 225-242

Bricklin, D., Frankston, B. and Fylstra, D. (1979). VisiCalc, Software Arts. Retrieved 31 May 2011 from http://www.bricklin.com/history/intro.htm

Burnett, Margaret M. (2010): End-User Software Engineering and Why it Matters. In JOEUC, 22 (1) pp. 1-22

Burnett, Margaret M., Cook, Curtis R., Pendse, Omkar, Rothermel, Gregg, Summet, Jay and Wallace, Chris S. (2003): End-User Software Engineering with Assertions in the Spreadsheet Paradigm. In: Proceedings of the 25th International Conference on Software Engineering May 3-10, 2003, Portland, Oregon, USA. pp. 93-105

Burnett, Margaret M., Sheretov, Andrei, Ren, Bing and Rothermel, Gregg (2002): Testing Homogeneous Spreadsheet Grids with the "What You See Is What You Test" Methodology. In IEEE Trans. Software Eng., 28 (6) pp. 576-594

Chambers, Chris and Erwig, Martin (2009): Automatic detection of dimension errors in spreadsheets. In J. Vis. Lang. Comput., 20 (4) pp. 269-283

Coblenz, Michael J., Ko, Andrew Jensen and Myers, Brad A. (2005): Using Objects of Measurement to Detect Spreadsheet Errors. In: VL-HCC 2005 - IEEE Symposium on Visual Languages and Human-Centric Computing21-24 September, 2005, Dallas, TX, USA. pp. 314-316

Costabile, Maria Francesca, Fogli, Daniela, Mussio, Pero and Piccinno, Antonio (2006): End-user development: The software shaping workshop approach. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 183-205

Cypher, Allen (1993): Watch What I Do: Programming by Demonstration. Cambridge, MA, The MIT Press

Diaz, Paloma, Aedo, Ignacio and Rosson, Mary Beth (2008): Visual representation of web design patterns for end-users. In: Levialdi, Stefano (ed.) AVI 2008 - Proceedings of the working conference on Advanced Visual Interfaces May 28-30, 2008, Napoli, Italy. pp. 408-411

Dittrich, Yvonne, Lindeberg, Olle and Lundberg, Lars (2006): End-user development as adaptive maintenance. In:Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 295-313

Erwig, Martin and Burnett, Margaret M. (2002): Adding Apples and Oranges. In: Krishnamurthi, Shriram andRamakrishnan, C. R. (eds.) Practical Aspects of Declarative Languages, 4th International Symposium - PADL 2002 January 19-20, 2002, Portland, OR, USA. pp. 173-191

Fischer, Gerhard and Giaccardi, Elisa (2006): A framework for the future of end-user development. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 427-457

Fischer, Gerhard, Lemke, Andreas C., Mastaglio, Thomas W. and Morch, Anders (1990): Using Critics to Empower Users. In: Carrasco, Jane and Whiteside, John (eds.) Proceedings of the ACM CHI 90 Human Factors in Computing Systems Conference 1990, Seattle, Washington,USA. pp. 337-347

Fisher, Marc, Rothermel, Gregg, Brown, Darren, Cao, Mingming, Cook, Curtis R. and Burnett, Margaret M. (2006):Integrating automated test generation into the WYSIWYT spreadsheet testing methodology. In ACM Trans. Softw. Eng. Methodol., 15 (2) pp. 150-194

Google (2010). Google App Inventor. Retrieved [Date unavailable] from Google:

Ichbiah, Daniel and Knepper, Susan (1992): The Making of Microsoft: How Bill Gates and His Team Created the World's Most Successful Software Company. Prima Lifestyles

Jones, Simon L. Peyton, Blackwell, Alan and Burnett, Margaret M. (2003): A user-centred approach to functions in Excel. In SIGPLAN Notices, 38 (9) pp. 165-176

Ko, Andrew J. and Myers, Brad A. (2004): Designing the whyline: a debugging interface for asking questions about program behavior. In: Dykstra-Erickson, Elizabeth and Tscheligi, Manfred (eds.) Proceedings of ACM CHI 2004 Conference on Human Factors in Computing Systems April 24-29, 2004, Vienna, Austria. pp. 151-158

Ko, Andrew Jensen and Myers, Brad A. (2008): Debugging reinvented: asking and answering why and why not questions about program behavior. In: Schäfer, Wilhelm, Dwyer, Matthew B. and Gruhn, Volker (eds.) 30th International Conference on Software Engineering ICSE 2008 May 10-18, 2008, Leipzig, Germany. pp. 301-310

Ko, Andrew J., Abraham, Robin, Beckwith, Laura, Blackwell, Alan, Burnett, Margaret M., Erwig, Martin, Scaffidi, Christopher, Lawrance, Joseph, Lieberman, Henry, Myers, Brad A., Rosson, Mary Beth, Rothermel, Gregg, Shaw, Mary and Wiedenbeck, Susan (2011): The State of the Art in End-User Software Engineering. In ACM Computing Surveys, 43 (3) pp. 1-44

Koesnandar, Andhy, Elbaum, Sebastian G., Rothermel, Gregg, Hochstein, Lorin, Scaffidi, Christopher and Stolee, Kathryn T. (2008): Using assertions to help end-user programmers create dependable web macros. In: Harrold, Mary Jean and Murphy, Gail C. (eds.) Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering November 9-14, 2008, Atlanta, Georgia, USA. pp. 124-134

Kulesza, Todd, Wong, Weng-Keen, Stumpf, Simone, Perona, Stephen, White, Rachel, Burnett, Margaret M., Oberst, Ian and Ko, Andrew J. (2009): Fixing the program my computer learned: barriers for end users, challenges for the machine. In: Proceedings of the 2009 International Conference on Intelligent User Interfaces 2009. pp. 187-196

Leshed, Gilly, Haber, Eben M., Matthews, Tara and Lau, Tessa (2008): CoScripter: automating & sharing how-to knowledge in the enterprise. In: Proceedings of ACM CHI 2008 Conference on Human Factors in Computing Systems April 5-10, 2008. pp. 1719-1728

Letondal, Catherine (2006): Participatory programming: Developing programmable bioinformatics tools for end-users. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 207-242

Lieberman, Henry, Paterno, Fabio, Klann, Markus and Wulf, Volker (2006): End-user development: An emerging paradigm. End User Development. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 1-8

Liu, Hugo and Lieberman, Henry (2005): Metafor: visualizing stories as code. In: Amant, Robert St., Riedl, John andJameson, Anthony (eds.) Proceedings of the 2005 International Conference on Intelligent User InterfacesJanuary 10-13, 2005, San Diego, California, USA. pp. 305-307

Mackay, Wendy E. (1990): Patterns of Sharing Customizable Software. In: Halasz, Frank (ed.) Proceedings of the 1990 ACM conference on Computer-supported cooperative work October 07 - 10, 1990, Los Angeles, California, United States. pp. 209-221

McDaniel, Richard G. and Myers, Brad A. (1999): Getting More Out of Programming-by-Demonstration. In: Altom, Mark W. and Williams, Marian G. (eds.) Proceedings of the ACM CHI 99 Human Factors in Computing Systems Conference May 15-20, 1999, Pittsburgh, Pennsylvania. pp. 442-449

Morch, Anders and Mehandjiev, Nikolay D. (2000): Tailoring as Collaboration: The Mediating Role of Multiple Representations and Application Units. In Computer Supported Cooperative Work, 9 (1) pp. 75-100

Nardi, Bonnie A. (1993): A Small Matter of Programming: Perspectives on End User Computing. Cambridge, Massachusetts, MIT Press

Newman, Mark W., Lin, James J. W., Hong, Jason I. and Landay, James A. (2003): DENIM: An Informal Web Site Design Tool Inspired by Observations of Practice. In Human-Computer Interaction, 18 (3) pp. 259-324

Oney, Stephen and Myers, Brad A. (2009): FireCrystal: Understanding interactive behaviors in dynamic web pages. In: IEEE Symposium on Visual Languages and Human-Centric Computing - VL/HCC 2009 20-24 September, 2009, Corvallis, OR, USA. pp. 105-108

Panko, R. (1998): What we know about spreadsheet errors. In Journal of End User Computing, 10 pp. 15-21

Powell, Stephen G. and Baker, Kenneth R. (2003): The Art of Modeling with Spreadsheets: Management Science, Spreadsheet Engineering, and Modeling Craft. Wiley

Repenning, Alexander and Perrone, Corrina (2000): Programming by Analogous Examples. In Communications of the ACM, 43 (3) pp. 90-97

Resnick, Mitchel, Maloney, John, Monroy-Hernández, Andrés, Rusk, Natalie, Eastmond, Evelyn, Brennan, Karen,Millner, Amon, Rosenbaum, Eric, Silver, Jay S., Silverman, Brian and Kafai, Yasmin B. (2009): Scratch: programming for all. In Communications of the ACM, 52 (11) pp. 60-67

Ronen, Boaz, Palley, Michael A. and Jr., Henry C. Lucas (1989): Spreadsheet Analysis and Design. InCommunications of the ACM, 32 (1) pp. 84-93

Rosson, Mary Beth, Sinha, Hansa and Edor, Tisha (2010): Design Planning in End-User Web Development: Gender, Feature Exploration and Feelings of Success. In: Hundhausen, Christopher D., Pietriga, Emmanuel, Diaz, Paloma and Rosson, Mary Beth (eds.) IEEE Symposium on Visual Languages and Human-Centric Computing, VL/HCC 2010 21-25 September 2010, 2010, Leganés-Madrid, Spain. pp. 141-148

Rosson, Mary Beth, Carroll, John M., Seals, Cheryl D. and Lewis, Tracy L. (2002): Community design of community simulations. In: Proceedings of DIS02: Designing Interactive Systems: Processes, Practices, Methods, & Techniques 2002. pp. 75-83

Rosson, Mary Beth, Sinha, Hansa, Bhattacharya, Mithu and Zhao, Dejin (2008): Design planning by end-user web developers. In J. Vis. Lang. Comput., 19 (4) pp. 468-484

Rosson, Mary Beth, Sinha, Hansa, Bhattacharya, Mithu and Zhao, Dejin (2007): Design Planning in End-User Web Development. In: VL-HCC 2007 - IEEE Symposium on Visual Languages and Human-Centric Computing 23-27 September, 2007, Coeur dAlene, Idaho, USA. pp. 189-196

Scaffidi, Christopher (2009). Topes: Enabling End-User Programmers to Validate and Reformat Data, PhD Dissertation, Technical Report CMU-ISR-09-105. Institute for Software Research (ISR), Carnegie Mellon University

Scaffidi, Christopher, Cypher, Allen, Elbaum, Sebastian G., Koesnandar, Andhy and Myers, Brad A. (2008): Using scenario-based requirements to direct research on web macro tools. In J. Vis. Lang. Comput., 19 (4) pp. 485-498

Scaffidi, Christopher, Bogart, Christopher, Burnett, Margaret M., Cypher, Allen, Myers, Brad A. and Shaw, Mary (2010): Using traits of web macro scripts to predict reuse. In J. Vis. Lang. Comput., 21 (5) pp. 277-291

Scaffidi, Christopher, Myers, Brad A. and Shaw, Mary (2009): Fast, Accurate Creation of Data Validation Formats by End-User Developers. In: Pipek, Volkmar, Rosson, Mary Beth, Ruyter, Boris E. R. de and Wulf, Volker (eds.)End-User Development - 2nd International Symposium - IS-EUD 2009 March 2-4, 2009, Siegen, Germany. pp. 242-261

Scaffidi, Christopher, Shaw, Mary and Myers, Brad A. (2005): Estimating the Numbers of End Users and End User Programmers. In: VL-HCC 2005 - IEEE Symposium on Visual Languages and Human-Centric Computing 21-24 September, 2005, Dallas, TX, USA. pp. 207-214

Segal, Judith (2007): Some Problems of Professional End User Developers. In: VL-HCC 2007 - IEEE Symposium on Visual Languages and Human-Centric Computing 23-27 September, 2007, Coeur dAlene, Idaho, USA. pp. 111-118

Wilson, Aaron, Burnett, Margaret M., Beckwith, Laura, Granatir, Orion, Casburn, Ledah, Cook, Curtis, Durham, Mike and Rothermel, Gregg (2003): Harnessing curiosity to increase correctness in end-user programming. In:Cockton, Gilbert and Korhonen, Panu (eds.) Proceedings of the ACM CHI 2003 Human Factors in Computing Systems Conference April 5-10, 2003, Ft. Lauderdale, Florida, USA. pp. 305-312

Won, Markus, Stiemerling, Oliver and Wulf, Volker (2006): Component-based approaches to tailorable systems. In:Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction Series)". Springerpp. 115-141

Wulf, Volker, Pipek, Volkmar and Won, Markus (2008): Component-based tailorability: Enabling highly flexible software applications. In International Journal of Human-Computer Studies, 20 (1) pp. 1-22

Yang, Sherry, Burnett, Margaret M., DeKoven, Elyon and Zloof, Moshé M. (1997): Representation Design Benchmarks: A Design-Time Aid for VPL Navigable Static Representations. In J. Vis. Lang. Comput., 8 (5) pp. 563-599

Zang, Nan, Rosson, Mary Beth and Nasser, Vincent (2008): Mashups: who? what? why?. In: Proceedings of ACM CHI 2008 Conference on Human Factors in Computing Systems April 5-10, 2008. pp. 3171-3176

10.7 Commentary by Alan Blackwell

Margaret Burnett and Chris Scaffidi provide an excellent overview of the evolving requirements in end-user development (EUD), and the technical approaches that have been taken to address them. In some ways, EUD provides one of the greatest challenges in interaction design - not because EUD tools are necessarily more complex than other specialist software categories, but because it can be harder to recognise the usability requirements. Designers in other fields must always stay alert to any presumption that customers will have exactly the same needs and habits as the designers themselves. However in the case of programming tools, it is all too easy for professional software developers to assume that every other person should approach his or her programming work in the same way as a professional does. Specialist research attention to end-users is necessary to avoid this trap when software professionals create new EUD technologies.

Successful EUD research can also provide benefits far beyond the target users. Software development can suffer from a "cobbler's children" effect - the usability of development environments is often poor by comparison to mass-market software categories where more has been invested in user research and interaction design. If EUD research leads to usability innovations for end-users, those same innovations can be later imported into mainstream software tools. A classic example is the Smalltalk language, which had superior usability because it had originally been motivated by the desire to create a programming language for children. Although children did find it useful, Smalltalk ultimately delivered far greater benefits by becoming one of the most usable object-oriented programming environments.

EUD is also providing new insights for HCI more generally. A recent focus on user-experience, and on products that meet market demand for "walk up and use" interfaces, has resulted in a lack of methods to understand requirements of more complex tasks, which involve interaction with information structures [1]. Simple media appliances and game-like interaction are welcome and desirable, but as Burnett and Scaffidi note in their conclusion, more sophisticated capabilities can also empower users. Lack of usability is frustrating, even in situations as commonplace as configuring social network privacy, or modifying a financial budget. The information structure in such tasks can be described as "programming-like", with more insight coming from EUD research than from standard usability methods. The field of Psychology of Programming [2] is able to provide guidance both to EUD, and to more domestic programming-like tasks, for example through the Cognitive Dimensions of Notations framework [3], and the Attention Investment model of abstraction use [4]. That field offers complementary insights to the very useful technical overview provided in this article.

References and links

1. Blackwell, A.F. & Fincher, S. (2010). PUX: Patterns of User Experience. interactions 17(2), 27-31.
http://www.cl.cam.ac.uk/~afb21/publications/BlackwellFincher-PUX.pdf

2. http://www.ppig.org/

3. Blackwell, A.F. and Green, T.R.G. (2003). Notational systems - the Cognitive Dimensions of Notations framework. In J.M. Carroll (Ed.) HCI Models, Theories and Frameworks: Toward a multidisciplinary science. San Francisco: Morgan Kaufmann, 103-134.
http://www.cl.cam.ac.uk/~afb21/publications/BlackwellGreen-CDsChapter.pdf

4. Blackwell, A.F. (2002). First steps in programming: A rationale for Attention Investment models. In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments, pp. 2-10.
http://www.cl.cam.ac.uk/~afb21/publications/HCC02a.pdf

10.8 Commentary by Mary Beth Rosson

End-user development is happening all around us. Burnett and Scaffidi do a good job of getting this message across, as well as surveying the many paths and supports for end users who participate in software development. But one issue that is hard to pin down is the why and who of EUD. HCI researchers have known for many years that people rarely become experts even in the use of their existing software applications (Rosson, 1984). So why would they choose to develop new software?

The answer to why lies in people’s real world goals. In some situations the task at hand depends entirely on building a computational artifact – e.g., creating a spreadsheet model, building a website for oneself or a group, learning science via a simulation, or connecting a set of equipment and their inputs and outputs for a lab experiment. Such situations qualify as EUD because the creator is not trained in software development and is building an artifact to meet other primary goals (e.g., education, business models). End users in these situations need tools and languages that can guide design: they must decompose their problems in a way that lets them map from domain knowledge and goals to computational abstractions and procedures. Sometimes a domain-specific language is the best approach, other times a generic creativity medium like a spreadsheet or web authoring tool.

An even larger set of EUD situations falls under the concept of tailoring as summarized by Burnett and Scaffidi. In these cases a person becomes dissatisfied with the functionality of a piece of software and changes it. This may be a change to how a bit of functionality is accessed or viewed (e.g., customization of keys, buttons or layout); a small and focused extension (e.g., defining a new document formatting style or recording steps to be repeated as a macro); or the redefinition of central aspects of an application (e.g., designing a better install configuration for a work group). Morch (1997) posits three levels of tailoring: customizing existing functionality; integrating functionality available elsewhere; and extending a system with new functionality created by end users. The degree of modification increases at each level, along with the impact of the sociotechnical context of use. That is, while simple customization may be entirely up to an individual user and his or her preferences, extending an organizational tool is the result of a complex social network of stakeholders, even if the actual change is enacted by a single individual (Mackay, 1990; Nardi, 1993). When a situation calls for tailoring, a critical aspect of the supporting EUD tools is integration with the abstractions and mechanisms of the existing application and associated practices (Costabile et al., 2006).

That leaves us with the question of who. Many scholars have pointed to the emergence of specific individuals in organizations, using metaphors like “gardener” to describe some people’s willingness to synthesize, abstract and support the computational needs present in their sociotechnical context (Mackay, 1990; Nardi, 1993). Others have noted the personal characteristics of individuals who appear intrinsically motivated to notice and explore new technology options (Rosson, Ballin & Nash, 2004; Zang & Rosson, 2010). The design of EUD languages and tools might certainly begin with an emphasis on evoking and supporting these tendencies. More worrying however, is evidence that some groups of end users (e.g., women and minorities) have a sort of learned avoidance about EUD, likely due to a myriad of personal, technical and social factors (Beckwith, 2007). The paradox of the active user (Carroll & Rosson, 1987) and the attention investment model (Blackwell, 2001) offer an essential lesson: only when EUD tools or languages can suggest or evoke benefits that are perceived to be significant enough – at the moment in time that an opportunity arises – should we expect to see a full range of end users enjoying the power that such tools bring.

References

  • Beckwith, L. 2007. Gender HCI Issues in End-User Programming. Ph.D. Dissertation, Computer Science Department, Oregon State University, Corvallis, OR.
  • Blackwell, A.F. 2002. First steps in programming: A rationale for attention investment models. In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments: VL/HCC 2002 (pp. 2-10). New York, NY: IEEE Computing Society.
  • Carroll, J. M., & Rosson, M. B. 1987. The paradox of the active user. In J.M. Carroll (Ed.), Interfacing Thought: Cognitive Aspects of Human-Computer Interaction. Cambridge, Mass: MIT Press (pp. 80-111).
  • Costabile, M.F., Piccino, A., Foglio, D. & Marcante, A. 2006. Supporting interaction and co-evolution of users and systems. Proceedings of Advanced Visual Interfaces: AVI 2006 (pp. 143-150). New York, NY: ACM Press.
  • Mackay, W. 1990. Users and Customizable Software: A Co-Adaptive Phenomenon. Ph.D. Dissertation, Computer Science Department, Massachusetts Institute of Technology, Cambridge, MA.
  • Mørch, A. 1997. Three levels of end-user tailoring: Customization, integration and extension. In M. Kyng & L. Mathiassen (Eds.), Computers and Context (pp. 51-76). Cambridge, MA: MIT Press.
  • Nardi, B. 1993. A Small Matter of Programming. Cambridge, MA: MIT Press.
  • Rosson, M. B. 1984. Effects of experience on learning, using, and evaluating a text-editor. Human Factors, 26(4), 463-475.
  • Rosson, M.B., Ballin, J., & Nash, H. 2004. Everyday programming: Challenges and opportunities for informal web development. Visual Languages and Human-Centric Computing 2004 (pp. 123-130). New York: IEEE.
  • Zang, N. & Rosson, M.B. 2010. Mashups for Web-active end users. In A. Cypher, M. Dontcheva, T. Lau & J. Nichols (Eds.), No Code Required: Giving Users Tools to Transform the Web (pp. 409-423). San Francisco, Morgan Kaufmann.

10.8 References