Allen Cypher

KidSim: programming agents without a programming language

oftware agents are our besf hope during the 1990s for obtaining more power and utility from personal computers. Agents have the potential to partiti

End-user programming of mashups with vegemite

xzte nrtively in accomplishing tasks, rather than serving as passive tools as do today’s applications. However, people do not want generic agents-they want help with lhtir jobs, their tasks, their goals. Agents must be flexible enough to be tailored to each individual. The most flexible way to tailor a software entity is to program it. The problem is that programming is too difficult for most people today. Consider:

KidSim: end user programming of simulations

Mashups are an increasingly popular way to integrate data from multiple web sites to fit a particular need, but it often requires substantial technical expertise to create them. To lower the barrier for creating mashups, we have extended the CoScripter web automation tool with a spreadsheet-like environment called Vegemite. Our system uses direct-manipulation and programming-by-demonstration tech-niques to automatically populate tables with information collected from various web sites. A particular strength of our approach is its ability to augment a data set with new values computed by a web site, such as determining the driving distance from a particular location to each of the addresses in a data set. An informal user study suggests that Vegemite may enable a wider class of users to address their information needs.

Programming by example: novice programming comes of age

KidSim is an environment that allows children to create their own simulations. They create their own characters, and they create rules that specify how the chammters are to behave and interact. KidSim is programmed by demonstration, so that users do not need to learn a conventional programming language or scripting language.

Novice programming comes of age

first commercial product based on PBD technology—Stagecast Creator, introduced in March 1999—enabling even children to create their own interactive stories, games, and simulations. Here, we describe this approach, offer independent evidence that it works for novices, and discuss why it works when other approaches haven’t and, more important, can’t. The computer is the most powerful tool ever devised for processing information, promising to make people’s lives richer (in several senses). But much of this potential is unrealized. Today, the only way most people are able to interact with computers is through programs or applications written by other people. This limited interaction represents a myopic and procrustean view of computers—like Alice looking at the garden in Wonderland through a keyhole. Until nonprogrammers can program computers themselves, they’ll be able to exploit only a fraction of a computer’s power. The limits of conventional interaction has

Making programming easier for children

Publisher Summary The limits of conventional interaction have long motivated researchers in end-user programming. The term “novice programmer” is used to describe end users who want to program computers. Since the late 1960s, programming language designers have been trying to develop approaches to programming computers that would succeed with novices. However, none of them has gained widespread acceptance. This chapter discusses a different approach in which traditional programming languages are eliminated in favor of a combination of two other technologies: programming by demonstration (PBD) and visual before-after rules. This approach is now available as a product named Stagecast Creator, which was introduced in March 1999. It is one of the first commercial uses of PBD. Stagecast Creator also enables children to create their own interactive stories, games, and simulations.

A1: end-user programming for web-based system administration

A conceptual gap exists between the # representations that people use in their minds when thinking about a problem and the representations that computers will accept when they are programmed. Introduction During the past 30 years there have been many attempts to enable ordinary people-people who are not professional programmers to program computers. Researchers have invented languages such as Logo, Smalltalk, BASIC, Pascal, and HyperTalk. They have developed techniques such as struc-tured programming. They have approached programming from a pedagogical perspective with technology, such as the goal-plan editor, [17] and from an engineering perspective, with CASE tools. Each of these is a brilliant advance in its own right. Today, however, only a small percentage of people program computers , probably less than 1 percent. A single-digit percentile is not success. We believe that there are at least two reasons for this low rate. First, traditional programming forces someone to learn a new language. Learning another language is difficult for most people. Consider the years of effort that it takes to master a foreign language. Second, programming languages are artificial languages rather than natural languages. They have a different epistemology. They deal with the unfamiliar world of computer data structures and algorithms. This makes them even less tractable for novices. The solution is to make programming more like thinking. In this paper we will show how a research project at Apple Computer has attempted to do this for childrens programming. The key ideas are to use representations in the computer that are analogous to the objects being represented and to allow those representations to be directly manipulated in the process of programming.

Integrating Learning Supports into the Design of Visual Programming Systems

System administrators work with many different tools to manage and fix complex hardware and software infrastructure in a rapidly paced work environment. Through extensive field studies, we observed that they often build and share custom tools for specific tasks that are not supported by vendor tools. Recent trends toward web-based management consoles offer many advantages but put an extra burden on system administrators, as customization requires web programming, which is beyond the skills of many system administrators. To meet their needs, we developed A1, a spreadsheet-based environment with a task-specific system-administration language for quickly creating small tools or migrating existing scripts to run as web portlets. Using A1, system administrators can build spreadsheets to access remote and heterogeneous systems, gather and integrate status data, and orchestrate control of disparate systems in a uniform way. A preliminary user study showed that in just a few hours, system administrators can learn to use A1 to build relatively complex tools from scratch.

Demonstrational interfaces: Coming soon?

The success of a programming system depends as much on the learnability of its language concepts as the usability of its interface. We argue that learnability can be significantly improved by integrating into the programming systemlearning supports that allow individuals to educate themselves about the syntax, semantics and applications of a language. Reflecting on our experience with developing novice programming systems, we identify infrastructural characteristics of such systems that can make the integration of learning supports practical. We focus on five core facilities: annotatability, scriptability, monitorability, supplementability and constrainability. Our hope is that our examination of these technical facilities and their tradeoffs can inform the design of future programming systems that better address the educational needs of their users.

Semiotic engineering in practice: redesigning the CoScripter interface

generalized instructions from direct manipulation. The problem is how to get instructions from the use~ Should she write them out? Should the system infer them from her behavior? Should direct manipulation interfaces include memory icons, expression boxes and event labels? I view the demonstrational interface as “instructible,” combining inference and direct manipulation to disambiguate action — to identify the relevant constraints on selecting and inserting data. In this case, the problem (for users and researchers) is to find instructions that specify constraints. Pure demonstration is activity without explanation. Typically, a machine learning system must see several examples before converging on the right constraint (for instance, “VI .ps” and “v2.ps” imply “v#.ps”; add “wow.ps” and you get “*.ps”). A direct instruction, “select file names ending in ‘ .ps’ ‘‘, eliminates inference. A focusing instruction, selecting or typing” .ps”, makes “*.ps” one of the first guesses to be tried, focusing is crucial if the user expects automation after very few examples. Finally, augmenting a direct manipulation interface with memory icons provides additional means of instruction. The other important problem is to identify control structure: loops, branches and subroutines. Loops and subroutines are inferred by matching and predicting actions; branches, by finding differences in preconditions before bad predictions. Direct instruction of a loop or subroutine requixes some means of selecting a sequence of events from history. Focusing instructions indicate approximate ranges of history. Direct and focusing commands help identify constraints as branching conditions. Tuwy: Experiments in Demonstration Protocol Turvy is a ‘‘ Wizard of Oz’ ‘, an instructible system portrayed by a human being. I chose this approach for two reasons: first, I wanted to use real applications like Word, MacDraw and HyperCard, whose internal data structures cannot be accessed. Second, I wanted experimental subjects to set their own protocol for instructing; hence Turvy has to speak and recognize language. Initially, the subject is told only that Turvy “watches what you do and understands a bit of English.” Owing to its familiarity with the tasks, Turvy appears to have programmatic rules of inference and limited background knowledge of basic spatial relations (contact, sequence and containment), basic structures of text and hypermedia (words, paragraphs, cards, fiekis, etc.), and that some characters are delimiters. The subject is allowed to practice an editing task, then invited to “teach” Turvy. At some point during a demonstration, the subject asks Turvy (or Turvy offers) to take over. My goal is to find the instructions people give with little or no training, and the types of prompts and feedback needed. Subjects invited to “tell” about a task either assume a human level of knowledge or give too much detail; those asked to “show” Turvy fare better. Users often teach kmps by demonstrating one iteration, then asking Turvy to “do it again” — without delimiting “it” exactly. In pilot studies I found that prompts for focusing confuse the use~ Turvy elicits instructions indirectly by verbalizing. Its choice of constraints sometimes appears incorrect, but people quickly learn Turvy’s “syntactic-level” bias. I have found a small set of useful instruction~ “watch what I do,” “you take over”, “ok”, “no — stop,” “do the next one,” “do the res