Settling for less than the Holy Grail

Position paper for CHI’99 workshop "End-User/Blended-User Programming"

 
Dag Svanæs
Department of Computer and Information Science
Norwegian University of Science and Technology
N-7034 Norway
dags@ifi.ntnu.no
© 1999 Dag Svanæs

Computer Literacy

In the preface of the book "Watch what I do" [Cypher, 1993], which sums up a decade of research in end-user-programming, Alan Kay writes: The term "computer literacy" also surfaces in the sixties, and in its strongest sense reflected the belief that the computer was going to be more like the book than a Swiss army knife. Being able to "read" and "write" in it would be as universally necessary as reading and writing became after Gutenberg. (p. xiii). Having described "reading" he continues: "Writing" on the other hand requires the end-user to somehow construct the same kind of things that they had been reading - a much more difficult skill. ... One of the problems is range. By this I mean that when we teach children English, it is not our intent to teach them a pidgin language, but to gradually reveal the whole thing: the language that Jefferson and Russell wrote in.... In computer terms, the range of aspiration should extend at least to the kinds of applications purchased from professionals. By comparison, systems like HyperCard offer no more than a pidgin version of what is possible on the Macintosh. It doesn't qualify by my standards [p. xiii]. There is little reason to believe that the current technological development alone will change this situation. Most of the popular windowing systems have internally grown increasingly complex during the 90s. The programming skills needed to implement inventive behavior on top of the current windowing systems now far exceeds what a curious user-interface designer can learn in her spare time.

A modern personal computer today consists of layer upon layer of constructed systems of abstraction, from assembler languages, through programming languages and user interface environments, up to the visible levels of the applications in use. The structure and content of these layers is the result of thousands of design decisions made by numerous programmers and systems architects over a long period of time. It is by no means determined by the hardware at hand as a lot of different systems of abstractions are possible. In constructing these abstractions the systems developers were constantly confronted with the trade-off between simplicity and expressive power. The necessary result is that for every new layer that was added to the software system, some part of the design space was lost.

From the point of view of a computer user with little or no skill in programming who wants to create interactive software, the current technological development has created the following situation:

Domain-specific vs. general tools

In her book "A small matter of programming" Nardi [Nardi ....] starts out by identifying the "holy grail" of EUP research: the old dream of building a user-friendly programming environment that gives ordinary users the expressive power of traditional programming languages. She argues that there are good reasons why this dream has never come through. One of the main reasons have to do with abstractions. End-users are not trained in the abstract thinking required to program a general Von Neuman computer. She argues that making the representations of the program specification visual does not remove this need for abstract thinking and understanding of concepts like algorithm, variable, data, state, and flow of control.

Having been the messenger of these bad news, she continues by showing a way out. Drawing from examples like knitting recipes and baseball charts, she shows that end-users can indeed work with complex formalisms as long as they are domain-specific. Her message is that in the design of tools for end users we should not be afraid of formalisms, given that we are very careful in hiding the underlying computer.

Does this mean we should just give up on the idea of providing end users with general computational tools? Our experience from observing kids learning to master the EUP-environment Cocoa makes us believe that Nardi might be a little too pessimistic.

Class-Instance in Cocoa (KidSim)

In a qualitative evaluation of the EUP environment Cocoa [Cypher ...], we observed the tool in use over a short period in a 6th grade class in our local International School. It is impossible to draw general conclusion from such little data, but going through the video tapes from the evaluation, we made some interesting observations of recurring problems. (The details can be found in [Spjelkavik 1999])

In the version of Cocoa (former KidSim) that we used, the kids see two main windows on the screen. A Cocoa "world" consists of a set of icons on a grid. The behavior is specified visually as graphical transition rules. The lower window shows the kind of icons in a sample world, while a large window above shows instances of these icons in their positions on the grid. To create a new instance of an existing icon class, one simply drags an icon from the lower window onto the grid.

Underlying Cocoa’s split in two windows is the computer science concept of the class-instance relationship. On several occasions we found that the kids had a different interpretation of the relationship between these two windows.

On one occasion a kid saw a class icon as a finite pile of icons to be placed on the grid. This came through in the quote "Let’s put all of them out there". This mental model is fundamentally different from the intended conceptual model, but it is functionally almost identical for single-instance instantiations. The only difference being that the pile is not infinitely large.

On another occasion the kids started an interesting discussion about the class-instance relationship and about object identity. In Cocoa one can name both classes and their individual instances. The children made a wolf class, and placed some wolves on the grid. Having done this they wanted to give one of the wolves a name. They named it "Hank". A discussion evolved around what new wolves would be called. If all new wolves became "Hanks", how could one distinguish one wolf from another? They ended up trying it out. Through this discussion they learned about Cocoa’s "world view".

From these and similar observations we concluded that the class-instance conceptual model used in Cocoa was not obvious to the users. Spjelkavik found as many as 6 different alternative understandings in use.

Cocoa’s Computational model

One of the groups developed a "world" where wolves ate rabbits. They first programmed the rabbits to move around on random. Next, they programmed the wolves to eat rabbits whenever a rabbit was in front of a wolf. Both rules worked very well when tested out separately, but when run in combination (free running rabbits together with rabbit-eating wolves) no rabbits were eaten. We were not able to help the kids with this problem, and contributed it at first to a bug in Cocoa.

Going through the tapes afterwards, we did a detailed analysis of the problem and found that with Cocoa’s computational model the rabbits would always escape the wolves before they got eaten. To understand the problem in detail we had to learn about Cocoa’s strategies for rule triggering. This analysis could not have been done by anybody without a background in computer science.

The interesting lesson learned was that with a relatively simple design, the system did not behave as expected due to Cocoa’s hidden computational model.

Lessons learned

From the above two problem areas in Cocoa, we conclude that it is important to make the "world view" and the computational model of end-user programming environments as explicit as possible. One way of doing this is through concrete metaphors. In the class-instance example one could for example use the factory metaphor often used in teaching object-oriented programming. By automatically placing the icons in the lower window inside factory icon, the users would hopefully understand the concept. The drawback with the factory icon is that it is misleading concerning "for all" rules. In the real world, you can not change the behavior of all existing cars of a certain brand by making changes to the car factory. These kind of considerations have to be done concerning all details of the designs. In additions, the choices of metaphor must be constantly validated through usability testing.

We believe that if care is taken in creating well structured magical worlds with well chosen metaphors, it is possible to build general end-user programming environments with more expressive power that the domain-specific systems proposed by Nardi. The full power of a programming language like Java might never be reached, but hopefully it is possible to build on the experience from systems like Cocoa and AgentSheets [Reppening] in making systems with enough expressive power to allow end-users to be creative also concerning systems behavior.

The power of LEGO

As a follow up on the Cocoa test, we plan to test LEGO’s MindStorms system with kids of the same age. Working with LEGO opens up for some reflections. Most kids love playing with LEGO, despite the fact that their end results rarely look very much like the object in the world that they model. A LEGO car built up from primitive square blocks can not compete with a photo-realistic toy car when it comes to the visual aspects, but the kids willingly pay this price to be able to put things together themselves. Most young kids do not care about the color of the blocks, but find great pleasure in assembling them into new objects. I have newer heard any kid complaining about the dots on top of the blocks.

The lesson to learn is that the end-users are willing to pay a high price concerning aesthetics to be given the power of constructing the structure themselves. Would there be a potential for a similar software tool, where a high price had to be paid concerning visual appearance and structural freedom to allow for the construction of behavior?

Is it possible to create a computational world with the simplicity of LEGO, and with enough expressive power to make it worth while for end users to learn? Would it then be possible to re-create large portions of today’s popular software on this platform, to open up for creative modifications and re-use of systems?

The holy grail of end-user programming research might never be achieved, but that should not stop us from trying to push the limit as far as possible towards systems that satisfy Kay’s vision of true computer literacy.

References

Cypher A., Watch What I Do, MIT Press, Cambridge, Ma, 1993

Nardi B., A Small Matter of Programming, MIT Press, Cambridge, Ma, 1993

Spjelkavik E., Klasse og Instans i slutt-bruker programmering, Masters Thesis,
Department of Computer Science, NTNU, Trondheim, Norway (forthcoming)