The subject matter of this book is creativity in the realm of invention and design. More specifically, it addresses the issues of how significantly original technological ideas or concepts may be produced by individuals. Questions such as this about the nature of the creative process are, of course, far from new. As Brewster Ghiselin pointed out in his introduction to The Creative Process, an anthology of writings on the topic, interest in creativity can certainly be traced back to the Greeks. It has continued to be thought about and written on ever since.

The premise of this book, however, is a relatively modern idea. It is the belief that it is possible to construct plausible, detailed, testable explanatory accounts of the cognitive processes underlying specific past acts of creation – acts such as the discovery of physical laws, the elucidation of biochemical pathways, or the invention of artifactual forms. The basic intellectual tool to be used in such explanations originates in the modern disciplines of cognitive science and artificial intelligence: It is the idea that computation-like processes of a certain, rather abstract kind can serve as a powerful metaphor with which to probe creativity and that, consequently, it is possible to obtain insight into the nature of specific acts of creation in a way and at a level of detail that has hitherto proved infeasible.

The means by which technological creativity is examined in this book is, in fact, a confluence of three distinct strands. One is the case study approach in which a specific episode from the history of computer technology, widely recognized as a highly original landmark, is singled out for study.

Problem recognition and formulation

The reader will recall from the section “The concept of creativity” in Chapter 1, that the criteria whereby a cognitive process P is deemed creative pertains to the nature of the product Π of that process. It is quite easy to be seduced into assuming, when we talk about Π, that we are really referring to a solution to some problem. This need not be so. Π may, in fact, itself be a problem and P the process of identifying it.

That the recognition of a problem and its formulation in a tractable or solvable form is one of the characteristic features of the creative mind – at least in the realm of scientific discovery and invention – is widely acknowledged (Sternberg 1988b; Root-Bernstein 1989). In the case of the invention of microprogramming, we have seen, according to the account in Chapter 3, that Wilkes was not presented with an “open” problem – that is, a problem already identified and acknowledged within the relevant community. He saw a problem others had not seen. The problem, it will be recalled, was conceptual in nature, having to do with such attributes as regularity and complexity. And as noted in Chapter 3 (section “On the conceptual nature of Wilkes's problem”), the recognition of such a problem by an individual is frequently inspired by a personal philosophical stance or set of values. This seems to have been the case with Wilkes, for, as he has remarked, it was essentially a “private” problem for him. Thus, at least in the case of microprogramming, problem recognition and formulation may be said to constitute an integral part of the overall concept formation activity.

In this chapter, I consider the potential and actual reuse opportunities within UNIX. First, several methods are suggested that could increase the likelihood that the next submission matches an item in a small set of predictions offered to the user for review and reuse. All methods are applied to the UNIX traces, and the predictive “quality” of each method is measured and contrasted against the others. In the second part of the chapter, I investigate how well the reuse facilities supplied by the UNIX shell are used in practice.

Conditioning the distribution

In the last chapter, particular attention was paid to the recurrence of command lines during csh use, and to the probability distribution of the next line given a sequential history list of previous ones. We saw that the most striking feature of the collected statistics is the tremendous potential for a historical reuse facility: the recurrence rate is high and the last few submissions are the likeliest to be repeated.

One may predict what the user will do next by looking at those recent submissions. But there is still room for improvement, because a significant portion of recurrences are not recent submissions. Can better predictions of the user's next step be offered? This section proposes and evaluates alternative models of arranging a user's command line history that will condition the distribution in different ways.

The recurrence distributions of Section 5.4.2 were derived by considering all input for a user as one long sequential stream, with no barriers placed between sessions.

Humans are the most versatile of creatures, and computers are their most versatile of creations. Human–Computer Interaction (HCI) is the study of what they do together; in particular, HCI aims to make interaction better suit the humans. Computers contribute to art, science, engineering, … all areas of human endeavor. It is no surprise, then, that there is heated debate about what the essence of HCI is and what it should be. What is good HCI? The answer to this question will be elusive given that there is good engineering that is not art, good art that is not science, and good science that is not engineering.

It's easier to see what form of answer there can be by taking a quick excursion into another field. Imagine the discovery of a dye, such as W. H. Perkin's breakthrough discovery of mauve. Is it science? Yes: certain chemicals must react to produce the dyestuff, and the principles of chemistry suggest other possibilities. Is it art? Yes: it makes an attractive color. Is it engineering? Yes: its quantity production, fastness in materials, and so forth, are engineering. Perkin's work made the once royal purple accessible to all. Fortunately there is no subject “Human Chemical Interaction” to slide us into thinking that there is, or should be, one right view of the work of making or using, designing, standardizing, or evaluating a dye. Nevertheless, we appreciate a readily available, stunning color, used by an able artist, and one that lasts without deteriorating.

Schemes for activity reuse are based upon the assumption that the human–computer dialog has many recurring activities. Yet there is almost no empirical evidence confirming the existence of these recurrences or suggestions of how observed patterns of recurrences in one dialog would generalize to other dialogs. The next few chapters address this dearth. They provide empirical evidence that people not only repeat their activities, but that they do so in quite regular ways. This chapter starts with the general notion of recurrent systems, where most users predominantly repeat their previous activities. Such systems suggest potential for activity reuse because there is opportunity to give preferential treatment to the large number of repeated actions. A few suspected recurrent systems from both non-computer and computer domains are examined in this context to help pinpoint salient features. Particular attention is paid to repetition of activities in telephone use, information retrieval in technical manuals, and command lines in UNIX. The following chapters further examine UNIX as a recurrent system, and then generalize the results obtained into a set of design properties.

A definition of recurrent systems

An activity is loosely defined as the formulation and execution of one or more actions whose result is expected to gratify the user's immediate intention. It is the unit entered into incremental interaction systems (as defined in Section 1.2.1) (Thimbleby, 1990). Entering command lines, querying databases, and locating and selecting items in a menu hierarchy are some examples.

This final chapter will be brief. First, the argument of the book is reviewed. Next, the original contributions are identified. Finally, new directions for research are sketched. The individual components of the book are not evaluated or criticized because this has been done at the end of each chapter.

Argument of the book

We began with the observation that orders given to interactive computer systems resemble tools used by people. Like tools, orders are employed to pursue activities that shape one's environment and the objects it contains. People have two general strategies for keeping track of the diverse tools they wield in their physical workshops. Recently used tools are kept available for reuse, and tools are organized into functional and task-oriented collections. Surprisingly, these strategies have not been transferred effectively to interactive systems.

This raises the possibility of an interactive support facility that allows people to use, reuse, and organize their on-line activities. The chief difficulty with this enterprise is the dearth of knowledge of how users behave when giving orders to general-purpose computer systems. As a consequence, existing user support facilities are based on ad hoc designs that do not adequately support a person's natural and intuitive way of working.

A portion of a trace belonging to a randomly selected expert programmer follows in the next few pages. The nine login sessions shown cover slightly over one month of the user's UNIX interactions, and include 155 command lines in total.

As mentioned in Chapter 2, all trace records have been made publicly available through a research report and an accompanying magnetic tape (Greenberg, 1988b). This report may be obtained from the Department of Computer Science, University of Calgary, or the author.

Because the raw data collected is not easily read, it was syntactically transformed to the listing presented here. The number and starting time of each login session are marked in italics. The first column shows the lines processed by csh after history expansions were made. The current working directory is given in the middle column. Blank entries indicate that the directory has not changed since the previous command line, and the “∼” is csh shorthand for the user's home directory. The final column lists any extra annotations recorded. These include alias expansions of the line by csh, error messages given to the user, and whether history was used to enter the line. Long alias expansions are shown truncated and suffixed with “…”.

This chapter examines how people use commands in command-based systems. Like previous work, it is based on an analysis of long-term records of user–computer interaction with the UNIX csh command interpreter, collected as described in the previous chapter. The results of the major studies are reevaluated, particularly those of Hanson, Kraut, and Farber (1984), and Draper (1984), and some of the work is replicated. Although the statistical results of the studies are supported, some of the conclusions made by the original researchers are found to be misleading.

The following sections provide details of how people direct command-based systems in terms of how individual commands are selected and the dependencies between these commands. It is essential to take into account the fact that pooled statistics may conceal important differences between individuals. As a consequence, the results are analyzed by user and by identifying groups of similar users, as well as by pooling data for the entire population.

For the current study, a command is the first word entered in the command line. Those lines that produced system errors were not considered. The first word is parsed by removing all white space at the beginning of the line and counting all characters up to but not including the next white space or end of line. For example, the command parsed from the command line

print −f 31 −t 40 galley.text

is “print.” The parsed word is almost always a true UNIX command or alias that invokes a program or shell script.

This chapter introduces a study of natural everyday human usage of the UNIX operating system and its command line interface. Analysis of the data collected is central to the pursuit of knowledge of user behavior when interacting with generalpurpose environments. The chapter begins by describing UNIX and gives reasons why it is an appropriate vehicle for research. Section 2.2 reviews several methods of data collection used with previous UNIX investigations, and Section 2.3 describes the details of the current study. Analyses of data are deferred to later chapters.

Choosing UNIX

Why perform natural studies on UNIX, with its baroque and outdated user interface, instead of controlled experiments on a modern system? This section starts by advocating a natural study for exploratory investigation of human–computer interaction. After recognizing several pragmatic problems with such investigations, UNIX is introduced and its choice is justified.

Natural studies

The thrust of the work presented in this book is that it is possible to capitalize on patterns evident in human–computer interaction by building special user support tools. A prerequisite is to “know the user” (Hansen, 1971). One way to accomplish this goal is through analyzing everyday natural user interactions with current systems so that existing patterns of activity can be discovered and exploited. Hanson, Kraut, and Farber (1984) justify this approach by contrast with traditional controlled experimentation.

It is evident that users often repeat activities they have previously submitted to the computer. These activities include not only the commands they choose from the many available in command-driven systems (Chapter 3), but also the complete command line entry. Similarly, people repeat the ways they traverse paths within menu hierarchies, select icons within graphical interfaces, and choose documents within hypertext systems. Often, recalling the original activity is difficult or tedious. For example, problem-solving processes must be recreated for complex activities; command syntax or search paths in hierarchies must be remembered; input lines retyped; icons found; and so on. Given these difficulties, potential exists for a well-designed “reuse facility” to reduce the problems of activity reformulation.

But most system interfaces offer little support for reviewing and reusing previous activities. Typically they must be completely retyped, or perhaps reselected through menu navigation. Those systems that do provide assistance offer ad hoc “history” mechanisms that employ a variety of recall strategies, most based on the simple premise that the last n recent user inputs are a reasonable working set of candidates for reselection. But is this premise correct? Might other strategies work better? Indeed, is the dialog sufficiently repetitive to warrant some type of activity reuse facility in the first place? As existing reuse facilities were designed by intuition rather than from empirical knowledge of user interactions, it is difficult to judge how effective they really are or what scope there is for improvement.