Communications of the ACM

Communications of the ACM

Building Personal Tools By Programming

By David Canfield Smith
Communications of the ACM, August 2000, Vol. 43 No. 8, Pages 92-95
10.1145/345124.345157
Comments

The most flexible way to personalize a PC or information appliance or computer network service is to program it. Since the PC is the most powerful information processing device ever accessible to ordinary people, personalizing it can significantly improve our ability to find, understand, transform, and communicate information. If it were possible for most people to build their own knowledge tools, it could transform their lives. Well, it is possible.

Today much of the potential PC power goes unrealized by most users. They must use programs (applications) written by others. This severely limits their freedom. It's like having a car that you can't drive. Instead, you must have a chauffeur to drive you around. Even worse, the chauffeur takes his orders from a company, not from you. Of course, the company tries to do the best it can in anticipating where you want to go, but...would anyone stand for such an arrangement?

They do with computers.

Why don't users simply program their computers and services themselves? It is the only way to access a significantly greater percentage of their power. People personalize computers in other ways. Are they fundamentally incapable of programming? Observe that people can give directions, write down recipes, explain rules of games, and generally both produce and follow sequential instructions—one of the key skills in programming. In my opinion, the fault lies not with computer users but with computer science, particularly, with the field of computer-human interaction (CHI). With all of bright CHI researchers in the world, it is disappointing to note that the problem of enabling novices to program computers hasn't been solved. People deserve better.

Two recent developments show that the solution is now within our grasp: an existence proof of novice programming, and faster computers.

Stagecast Creator™ [1] allows visual simulations to be built so easily that anyone can do it. A visual simulation is a computer program in which objects move about on a display screen interacting with each other. Most video games are visual simulations. Figure 1 shows an example. The plot here is that white blood cells have to defend the body from germs. The window on the right shows some of the rules for white blood cells. The rules are programmed by demonstration, and the resulting programs are displayed as visual before-after rules.

This combination of technologies is the key to making programming doable by novices. Numerous studies have shown that children as young as five years old can create visual simulations with Creator, and they enjoy doing it. My summary of these studies is that essentially everyone who wants to can program computers in this way.

Faster computers make it practical to run such simulations as part of the standard interface. In order to be usable by novices, programs must be interpreted or at least compiled transparently. With today's fast PCs, this level of inefficiency is no longer an issue.

Back to Top

Criteria for Novice Programming

OK, so Creator can be used to make video games. How is that relevant to what people do with computers in the real world? This is the crux of the matter. My answer is optimistic: With the Creator approach, end users can program on a computer any subject matter in which they are interested.

I admit this is unproven—although it's testable. I see no domain that is inherently off limits to novices. They won't program a compiler or device driver, but they aren't interested in those applications. I think we can make the applications in which they are interested programmable.

The Creator approach to programming incorporates the following requirements:

1. Visual domain. Data must be represented as visual objects on a computer display screen.
2. Direct manipulation. Users must be able to manipulate the objects with the mouse.
3. Interactive. The results of user actions must be displayed immediately. This is necessary to establish cause-effect relationships.
4. Programming by demonstration. User actions must be recordable and generalizable. This makes writing programs as easy as operating the interface, which people do anyway.
5. Visual domain-specific program representation. Programs must be represented as visual before-after rules in which the left side of the rule shows a portion of the domain before the rule executes, and the right side shows how it will appear after the rule executes. The objects shown must be in domain terms instead of computer terms.
6. Execution control. Precise control over execution is necessary to help users understand programs. In particular, they must be able to single step a program one simulation clock tick at a time. (The semantics of a "clock tick" varies from simulation to simulation.) They must also be able to single step it backward one tick at a time (undo). Being being able to undo reduces people's anxiety and encourages them to experiment.

I have been working on these requirements for 25 years. Allen Cypher, the coinventor of Creator, has likewise devoted years of study to them. While other criteria for novice programming may also work, we know the ones we mention here do work.

Back to Top

Programming the Finder

There are no PC environments other than Creator that meet these requirements, at least outside of research labs. To illustrate how other domains could be programmed by novices, we will discuss the specific example of the Macintosh Finder.

The iconic interface to the Macintosh computer is called the "Finder." It presents computer resources such as disk files and devices as pictures (icons) on a metaphorical desktop, such as documents, folders, bookshelves, wastebaskets and telephones. These are things that one would find in a typical office. (The Windows desktop is similar and can be substituted for the Finder here.) This interface clearly satisfies our first three criteria for a programmable environment. With AppleScript it even allows some actions to be recorded. Although the actions it records are bound to specific data objects, users can manually generalize the actions later by editing the script. Where the Finder is lacking in programmability is in criteria 5 and 6. Instead of a graphical representation for a program, it uses a textual one. For example, Figure 2 shows part of an AppleScript program to make an alias for an icon.

Two other subroutines (not shown) are included. Note that none of this is in terms of icons and aliases; it is in terms of procedures, variables, loops, conditionals, and other control structures. Prevailing evidence is that few people can understand—let alone create—such representations. The problem is it is a generic representation; it looks the same no matter the topic. What is needed is a domain-specific srepresentation that deals with Finder objects.

Suppose instead this program were represented as in Figure 3. Which is easier to understand? It is not necessary (and, in fact, undesirable) to show every step in a program in the representation. Instead, rules act as visual reminders of what the program does. If people need to see the individual steps, they can; but they shouldn't be forced to see the details. The principle of information hiding is well established in the CHI literature.

But more is involved than just changing the name of the program to be a visual rule. The actions in the program must also be specially tailored to the domain. In this case, for example, the primitive actions such as Move, Copy, and Delete should all work on icons. To program this task in the Creator style, one would start recording, select an icon, invoke the Make Alias command in the File menu, open the Apple Menu Items folder, drag the alias into the folder, and stop recording. One would stay at the Finder level dealing with Finder objects, never descending into programming language syntax. Domain-specific programming is essential for novices.

The second deficiency in AppleScript's programming of the Finder is in control of program execution. Once an AppleScript script starts executing, it runs at full speed to completion. By contrast, Creator provides a control panel that gives users fine-grain control over execution, as shown in Figure 4.

This is deliberately similar to a VCR control panel. The red button stops a running simulation. The yellow buttons single step it forward or backward one simulation clock tick. The green buttons start it running forward or backward. The clock shows whether the simulation is running, whether it's running forward or backward, and how fast it's running. The radio buttons under the tortoise and hare symbols control how fast it runs. Such control is essential to understanding programs.

Making these changes to the Finder would significantly improve its programmability. In general, in order for a domain to be programmable by novices, it must have its own domain-specific environment. If there are 10 domains, there must be 10 environments. Each environment will present a set of domain objects to use for programming. What they won't present is a bunch of computer terms and concepts. While making these environments is a great deal of work, I believe there is no other solution.

Back to Top

Summary

By carefully applying well-established CHI principles to the task of programming, it is possible to construct programming environments that make it feasible for anyone to program computers and services. This can open up a brave new world in which computers become more powerful and useful than ever before. In the future, people will literally program their own interfaces.

We have given an existence proof—Stagecast Creator—that anyone who wants to can program. We have presented a set of criteria that allows Creator's approach to be applied to other domains. It will still require hard work and innovation to construct programming environments for each domain, but there may be no more worthwhile goal for computer science as we enter a new century.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

---

No entries found