End-user programmers create software to solve problems, yet the problem-solving knowledge generated in the process often remains tacit within the software artifact. One approach to exposing this knowledge is to enable the end-user to annotate the artifact as they create and use it. A 3-level model of annotation is presented and guidelines are proposed for the design of end-user programming environments supporting the explicit and literate annotation levels. These guidelines are then applied to the spreadsheet end-user programming paradigm.
End-user programmers' principal goal is to solve problems, not write programs. However, the mechanics of solving problems through programming -even when the user is not intentionally writing code, as in traditional programming -often take precedence over documenting the solution. The resulting software artifact contains within it the tacit problem-solving knowledge gained in the process of not only creating it, but of putting it into practical use. Because this knowledge is rarely made fully explicit, reusability as both a software and knowledge artifact is reduced.
A significant challenge is finding a means to document problem-solving knowledge in an unobtrusive, seamless manner. If the cost of capturing the knowledge is greater than the perceived benefit, a user is unlikely to do it. This is largely a matter of design; regular users of a tool will know the challenge of deciphering an artifact they themselves created, so there is certainly incentive to document for themselves. Those engaged in collaborative problem-solving endeavors have an incentive to share, and a design that enables, at a minimum, the kind of simple, in-process note-taking common to this work [Markus, 2001] is a worthy objective toward satisfying this requirement.
An apt place to start is with the spreadsheet. It is by far the most popular end-user programming tool [Jones et al., 2003]; its widespread use in the financial industry and other domains has led to the recognition that errors can be costly [Panko, 1998]; these are certainly software errors, and as such, there are efforts to bring software engineering-like practices to the creation of spreadsheets and other end-user development media [Burnett et al., 2004].
A common solution that potentially satisfies both requirements -to capture knowledge and reduce errors -may be found in designs supporting structured annotations. Knowledge is made explicit through annotation [Marshall, 1998] and there is evidence that structured combinations of code and documentation reduce errors and improve maintainability [Oman and Cook, 1990]. The objective of this work is to combine and extend these ideas in the end-user development space, with an initial focus on the spreadsheet paradigm. This paper begins by scoping the work around problem-solving knowledge transfer and typical methods of achieving this in software development. A model of end-user development annotation is introduced as a framework for a collection of guidelines for integrating annotation as a means of knowledge documentation into the end-user programming paradigm. These guidelines are then applied to the spreadsheet end-user development modality, and a plan for evaluating the resulting designs is described. Finally, related work is compared to the proposed approach.
This work focuses on improving the transfer of problem-solving knowledge. This is formally defined as the ability to apply previously learned knowledge to solving a new problem [Mayer and Wittrock, 1996]. In this process, prior learning helps new learning; this effect is increased when the prior learning -that is, the hard-won problem-solving knowledge learned by another -is codified in such a way to make it useful to someone taking on a new problem. A common approach to this is analogical problem solving, in which the solution to a previous, but analogous, problem is tailored to the new problem. The challenge then becomes in finding analogous problems and solutions to reuse.
The degree of codification of the knowledge is closely related to the concepts of tacit, implicit and explicit knowledge [Polanyi, 1966;Wilson, 2002]. Briefly, tacit knowledge is that which is unexpressed and largely inexpressible; implicit knowledge is partially expressed but may require additional knowledge -some “common sense,” at least as far as the expresser of the knowledge is concerned -to understand it; and explicit knowledge is fully stated and generally reusable as is. Many challenges face efforts to effectively represent and share knowledge, and these are often beyond the purely technical, requiring engineering in the larger socio-technical domain [Fischer and Otswald, 2001].
To scope this challenge, a useful point of departure is to identify the elements of problem-solving knowledge that need to be communicated. As adapted to computerbased problem solving by Mayer [2002], there are four kinds of knowledge of interest to knowledge transfer: declarative, conceptual, procedural and metacognitive. For a software artifact, generally only the procedural and perhaps elements of the declarative knowledge associated with a program are represented within it; capturing the other elements requires additional documentation.
In traditional programming, a number of mechanisms have been employed to capture programmer knowledge, principally various forms of documentation internal and external to the source code. Certainly the most common method is the use of comments within the code, and conseque
This content is AI-processed based on open access ArXiv data.