At Xerox, we have embarked on a long range programme concerned with personal computing. My own interest goes back to the late 1960's at Utah where the FLEX machine was built. This consisted of a desk top graphical machine which directly executed a high level simulation language. It turned out to be more successful technically than from the user's point of view. An important result of this work was the realisation that the man-machine interface was more important than the technical facilities that could be provided. If the user cannot understand the facilities being made available, he certainly cannot use them.
At Xerox in 1971, it was decided to anticipate what technology would be available in 1982 and to set up a 10-year project to do the software development for the hardware that would be available then. The hardware could be designed and built later. It was envisaged that the machine would execute 100 billion instructions per second and would be the size of a notebook with a flat panel display and capable of running off batteries.
Most of the software development is done using the Xerox PARC Alto system {there are about 650 in existence). It executes about 6 million instructions per second and has a high resolution display. The main pointing device is the mouse. One of our main concerns in the design of a personal computer was not to give the user less than he was already used to. A major problem with computers is that in the guise of giving you something more, they always take something away. For example, there are very few displays around which allow you to produce printed quality text with a variety of fonts and half-tone illustrations. The Alto display allows you complete freedom to manipulate a bit-map display with 500,000 dots - about the capabilities and resolution of a newspaper.
We chose the name SMALLTALK partly to have a connotation with children and partly because I was tired of naming systems after Greek Gods. With impressive names, you always expect that the system is going to do something impressive for you -and they never do. We feel that SMALLTALK is about the level of communication possible with computers.
SMALLTALK is a high level language that gets some of its ideas from SIMULA. The language does not have data structures and procedures as elementary building blocks. Everything in the system is programmed in SMALLTALK and there is no separate operating system. For personal computers where there are going to be millions of them and millions of users, it will be impossible to forecast what users will need. Therefore, the system must be moldable by the user.
In SMALLTALK, everything is built from active communicating objects. Every SMALLTALK object has an inside and an outside. The outside may be quite different from the inside. The outside is all that the user ever gets to see. The only way that a user can communicate with a SMALLTALK object is to send it a message, that is to an object's outside. The object can decide whether it wants to answer or act upon the message or not. Objects from the outside act like digital computers in a communications network. The inside is some mixture of state and process unknown to the user. The user sends messages to the object and has some faith in what the replies are going to be like. Faith is important because we never understand what is going on inside a complex object like a computer. There is a lot of religion in Computer Science and we capitalise on that. The user communicates by asking questions of an object and getting back answers. However, you cannot force an object to do anything in SMALLTALK. There is nothing like an assignment statement which could change the state of an object. You can ask an object to change its state but it may refuse.
The inside of an object is only known to its programmer. The programmer of an object can change its method for carrying out its virtual meaning at any time as long as its external behaviour stays the same. This concept of objects is a good framework for building an operating system. Protection is automatic and the object definition forms a basis for defining a capability based operating system. Each denotation of an object is a capability for that object. This is the approach that has been adopted in building the operating system functions within SMALLTALK.
In SMALLTALK, we try and use the smallest number of the most powerful metaphors for describing the system both to ourselves and to other people.
Viewing an object uses the standard window/viewport technique. There are a set of viewports on the display screen and windows which are used to project objects onto the screen. Viewports may overlap. In SMALLTALK, windowing an object is done not just for display purposes but for any kind of use where you want to refer to the object. The term filtering is used for this more general type of viewing.
Filtering provides an excellent mechanism for developing interfaces of all kinds both to the human user and to other objects. Editing a view of an object may change the state of the object and will be continuously reflected back through all the other views of the object.
The insideness and outsideness of an object is constructed by filtering. The outside of an object is portrayed by a filter that suppresses internal organisation for a simpler external fiction.
Classes are descriptions for objects. Classes range from quite mundane things such as class number, class bit to quite complex objects such as class document and class window.
An instance is a particular view of a class. The class has all the things that are similar about the instances. The instances have the things that are different between each other. Because the instance inherits information from the class, you can think of an instance as a view of a class.
Deriving an instance of a class may create a distinctly new object. Identity-changing filters of this type allow a second level of systems structuring a way to describe the kinds of objects we wish to gather together to carry out our wishes.
Superclasses can be defined which can be filtered to define specific classes. For example, you could have a superclass which defines strategies for containing objects but of no particular kind. Subclass filters may generate classes for how to contain text or how to contain illustrations. You might even generate a subclass for how to contain object containers.
Filtering is used to create new objects that are dynamic analogies of objects we already know about. Instances of classes and superclasses are examples of this kind. The analogy filtering mechanism permits classes to be defined that are similar to other classes. System designers can define super object descriptions from which analogies may be extracted.
Having such descriptions in the system does have its problems. On the positive side, users do not have to invent classes every time they use the system but can normally fabricate the ones they require from those existing in the system. On the negative side, the number and variety of these descriptions means that more attention must be paid to providing ways for the user to examine them.
A class of browsers has been introduced which provide a general mechanism for retrieving information about the system. A browser divides the screen of the display into a set of panes - as in a glass window. The panes in the browser depend on one another and define a way of retrieving information. Selecting something in the menu in one pane will cause a new menu to be retrieved into the next pane. Selecting something in this menu will cause a display to be retrieved into the next pane and so on.
Browsers exist for most parts of the system and most applications.
Two levels of structuring have been introduced so far. The first level includes the concept of objects having inside and outside properties with filters that can act upon them. The second level uses the first to define objects that act as prototypes from which new objects may inherit analogous characteristics. The first level is the kernel of the system and we build our second level inheritance mechanism in terms of classes, instances and superclasses (similar to SIMULA but more general and dynamic).
However, having classes is not enough. You can program everything in terms of classes but, if you are not careful, the number of classes grows rapidly. Already there are 70 or 80 classes in SMALLTALK. There is no real organisation in the classes themselves.
We, therefore, define a third level of structuring and try to build things in terms of models. A model imposes sharply orthogonal properties on a small number of primal classes and you inherit from these.
A particular model that has been used is in terms of domains, travellers, and decorations. A domain is a spatial metaphor and can be the basis for a wide variety of descriptions such as numbers, documents, circuit diagrams, musical scores, and animation scenarios.
The traveller is the entity that can move from place to place in the spatial domain. Examples of travellers are a cursor in a document, a player in a musical score, or a role in an animation scenario.
Decorations are those things that enhance the traveller's journey but do not change the meaning of the journey. For example, different type fonts in a document, different instruments playing the musical score, or different costumes in the animation.
Programs, themselves, represent a domain. The traveller is the program counter and the decorations are the particular type of interpreter used to obey it. In SMALLTALK, many things are built out of these three superclasses.
Kits is a fourth level of structuring in SMALLTALK. A kit is a further filtering on a domain which focuses its degrees of freedom to a particular goal. The analogy in the real world is that you go to a store to buy something and you cannot find what you want. The next option is to try and find a kit which allows some degrees of freedom in structuring it. If you cannot find a kit, you have to fall back on getting wood and other materials to build it from.
Kits exist in SMALLTALK for document editing, drawing and painting, music, animation and even programming.
On top of the kit you can think of a fifth level of structuring which you might call an application - a layer of structure that has almost no degrees of freedom because the use of it is so stereotyped.
If things are built in these layers, the user of an application, if it gets into trouble, can retreat to the kit level if the application was formed from a kit. The user does not have to go all the way down to classes and instances in order to try to understand it.
SMALLTALK is not a load and go system such as PASCAL. It has a large virtual memory - the one that currently exists has been alive for over three years. Everything that is done to the system is incremental. The virtual memory is constantly being enriched and so any compilation and editing that is done has to allow for the existence of objects which depend on restrictions that we may wish to change. The compiler is an incremental one and has been effective in allowing for such changes.
SMALLTALK is a message-object language used as a complete system for building things. Operating system functions for allocating actual and virtual resources are modelled in the system. All of the scheduling and synchronisation is done by virtue of the viewing and message sending process.
One question that should be answered is why should there not be a class called User. This is a class that tries to model abstractly the properties of a particular user of the system. Such a superclass could be used to build user interfaces from, instead of building them from scratch. Such a class would be hard to define as it is very abstract. A class User does exist in the system but it is not nearly as interesting as it should be. It is just a class that acts as the carrier of all the information that the user is likely to send into the system.
(1) A.Kay, 'Ideas for Novice Programming in a Personal Computing System', Infotech Conference on User Friendly Systems, March 1978.
[Editor: this paper was produced at the end of the Workshop. However, it is appropriate to place it here as it brings out those features of SMALLTALK which were discussed at length during the Workshop.]
A human confronts a computer primarily to control it, to operate it as a very complex tool to perform a task, simple or complex. The computer tool differs from most in that it is usually moulded to form new tools for others to use. These tools are, in turn, controlled by users with specific objectives, or tasks, in mind.
SMALLTALK is both a language and an interactive programming environment; it is a mechanism for building tools and a tool for building programs. We might ask whether the SMALLTALK language itself is designed to ease the programming of means to control these new tools. We might also ask whether the SMALLTALK environment offers any help. It is important to remember that the language and the environment are different.
What relationship is there between the abstractions of data and control in a programming language and the control constructs of interactive programs written in the language? No language can insist that a direct relationship exist, because a program can always be written to interpret some other language. This approach is taken, for example, by table-driven command language parsers.
Constructs in the programming language may offer conveniences in designing the user interface. The concept of object appears often in the control of SMALLTALK programs. An object is told to show itself on the display. The object detects whether the cursor is pointing at it and whether a mouse button is struck; the object modifies itself as a result of the user's action; the object then shows itself again, in the modified form. This theme acquires considerable power because objects may contain other objects, which in turn contain others and so on.
It is worthwhile noting that input and output control are not symmetric in the SMALLTALK environment. Output is ultimately generated by sending messages to an object that alters the display. Input devices, on the other hand, are polled, usually by sending messages to them. Thus mouse x returns a co-ordinate, mouse buttons returns a description of all depressed keys. This programming convention makes it easy for many objects to attend to input activity concurrently. It is certainly possible to use an alternative convention in which input devices send messages to objects, although this scheme would make many of SMALLTALK's interactive effects difficult to achieve. The polling scheme allows each object to detect different significant events in the input.
Another theme from the SMALLTALK language appears on the screen - concurrent processes. Windows seem to be active objects, waking up when the cursor enters one and becoming dormant when the cursor is moved off to other regions of the screen.
Do control structures such as procedures for other programming languages show up in user interfaces? The prototypical READ-EVAL-PRINT loop of LISP forces a strict control regime on the interaction. This is sometimes softened by communicating with the user with versions of READ PRINT that offer special conveniences: PRINT may limit the depth of list output; READ may provide abbreviations, check spelling, or quote arguments. Present-day LISPs have incorporated other control constructs such as processes and coroutines (Interlisp).
The relationship between control structures of a programming language and those of a user interface is by no means firm. At most, the structures of the programming language suggest structures in the interactive language. But I cannot tell when I press buttons on a microwave oven, what control structures are used to program the microprocessor I am controlling.
The emergence of distributed computing is fostering development of control mechanisms by which a program running in one machine, controls programs running in others. Not surprisingly, these communication protocols exhibit many of the characteristics found in the user interfaces, used to control similar programs [1]. Alas, they also exhibit many of the problems observed in the design of user interfaces. The designer needs to identify a control language that expresses the interactions between two programs, to encode that language as a sequence of bits, and to transport the bits from one program to another.
The SMALLTALK programming environment is far more important in setting the interactive style for typical SMALLTALK programs than is the language itself.
Thebrowser is a conceptual framework that organises most of the interaction between SMALLTALK and the programmer: editing class definitions, diagnosing errors, and so forth. Individual programmers have adapted this framework for separate applications, music, animation, planning, job-shop simulation, relational systems, etc. In these cases, the programmer has adopted a good deal of the browser implementation, and has adapted the rest to suit his needs. SMALLTALK eases this task by requiring the programmer to specify only the modifications to the browser framework, and not to build an entire browser from scratch. The SMALLTALK environment thus sets an overall style of control that is frequently easily adapted to new applications. The framework provided by the environment offers a useful suggestion to the designer of an interactive program. At the same time, it does not preclude innovative departures by an adventurer. The interactive style of the SMALLTALK environment has evolved constantly since the language first ran. Each iteration has drawn upon existing applications, and produced a new environment that accommodates them all. Thus, we see an interactive framework that has been done, redone, and improved constantly. We see now the cumulative result of many refinements by talented designers.
I know of no programming environment that has so successfully explored interaction and programming together. SMALLTALK aims both to achieve excellent interaction and, via programming, to be useful in a wide variety of applications.
Other interactive programming environments - Interlisp, APL, BASIC, and more - have the potential to provide high-quality interaction and to become environments in which interactive applications are easily built. The lack of proper hardware has been a deterrent. When offered a reasonable display, Interlisp evolved fairly easily into a display-oriented programming environment, DLISP [2]. I believe that significant additional effort would be required to grow DLISP into a facility for building interactive programs of such wide scope as SMALLTALK.
The hardware that promotes the intimate control of SMALLTALK is now becoming available. The PERQ contains all the essential ingredients of the Alto, on which SMALLTALK is based [3]. It is becoming easier and easier to design such computers, although they are admittedly slow to come to market.
The importance of thinking carefully about hardware and systems should be stressed. In my view, designers of interactive systems have been repeatedly victimised by ancient, stilted views of interaction enforced by operating systems, programming language I/O routines, and terminals. I have not enjoyed the obligatory battle with these obstacles [4].
Intimate, effective control of a computer program is clearly achievable -SMALLTALK shows examples. Spreading this kind of interaction does not require spreading the SMALLTALK language, but may well require building environments as rich as that offered by SMALLTALK. I believe also that we cannot tolerate closed, unmodifiable systems that restrict the control of output to the user on the receipt of user inputs.
(1) R.F.Sproull and D.Cohen, 'High-level Protocols', IEEE Trans. Communications, Nov. 1978.
((2) W.Teitelman, 'A Display-oriented Programmer's Assistant', Proc. 5th IJCAI, 1977. Also available as a technical report from Xerox Palo Alto Research Centre.
((3) 'PERQ - A Personal Computer', Three Rivers Computing Corp, Craig St., Pittsburgh, Pa 15213.
((4) R.F.Sproull, 'Raster Graphics for Interactive Programming Environments', SIGGRAPH 1979
((5) W.M.Newman, 'Some Notes on User Interface Design', position paper to Seillac II.
((6) W.M.Newman and R.F.Sproull, 'Principles of Interactive Computer Graphics', McGraw Hill (2nd Edition).
