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.

This book opened by advocating the common metaphor of tool use for thinking about command-based systems, where command lines are the tools people employ to manipulate the materials in their computer environment. The four preceding chapters pursued the notion that recently used lines, like tools, should be available for reuse. But reuse is not the only strategy for supporting user activities. It is evident that people impose some organization on their computer tools and materials, just as craftsmen do with their physical counterparts. Real workshops support these organizations through toolboxes for arranging and locating tools, workbenches for performing specific tasks, shelving and drawers for keeping relevant tools and materials readily available, and so on. Computing environments, on the other hand, do little to promote personal organization. A command-based interface is comparable to an unhelpful clerk who waits for you to name the tool you want, retrieves the tool (if available) from a separate room, and demands that you return it immediately after use. At the other extreme, arranging facilities into fixed taxonomic menus is reminiscent of a totalitarian chaining of tools to a single location.

General-purpose computer environments that furnish a large set of diverse tools are often hard to use. Although some difficulty is associated with using any particular tool, this book is concerned with the problems that a person faces when selecting a tool from the many available, reusing that tool while performing a task, and organizing the chosen tools in a way that makes them ready to hand later on. Surprisingly, methods and habits for using physical tools that have evolved over millions of years have not been transferred effectively to the computer domain.

The goal of the research discussed in this book is to identify properties of a human–computer interface that supports how people select, reuse, and organize the tools available in general-purpose computing environments. These properties come from empirical analyses of user behavior. This introduction sets the scene first by reviewing physical tools, from their very natural use by animals to ultra sophisticated machinery that taxes human capabilities beyond acceptable performance limits. Section 1.2 moves to the focus of this book – general-purpose computing environments that make diverse collections of on-line tools available. It identifies two problem areas: the dearth of knowledge about people's use of on-line tools, and the poor existing user support for everyday interactions with them.

The following pages list a few basic statistics observed for the subjects involved in the study. Each subject is identified by the name of his group and a number. For example, “Novice–1” is the first subject of the Novice Programmer group. These names match the file names found in the publicly available trace data (Greenberg, 1988b).

The statistics include each user's number of login sessions, the command lines entered, the different commands used, the csh errors noted, the times history was used, and the different directories accessed. For example, Novice–1 entered 2,457 command lines over fifty-five login sessions. Of those lines, 213 produced csh errors. History was invoked thirty-seven times, eighteen different directories were visited, and sixty-seven different commands were used.

This chapter describes a design and implementation of a user support tool that embodies the reuse properties suggested in Chapters 4 through 7, and the workspace organization of Chapter 8. Called WORKBENCH, the system is a graphical window-based front end to UNIX csh. The facilities and user interface are described in the first section, along with the rationale behind its design. WORKBENCH is not an end in itself. Although recently made available to selected members of the University of Calgary's Department of Computer Science and now used by several people, it serves here as an exploration of a workspace design. It is not formally evaluated; experimental appraisal is neither credible nor necessary at this early stage. Rather, the intent is to discover how feasible it is to build a workspace, to note initial pragmatic considerations arising from its use, and to suggest research areas motivated by problems encountered or envisaged. These issues are covered in the second section.

The WORKBENCH system

WORKBENCH is a window-based facility that allows people to reuse and structure their on-line UNIX csh activities.

The two preceding chapters analyzed command line recurrences with dialogs with the UNIX csh. Based on the empirical results, the first section of this chapter formulates general principles that characterize how users repeat their activities on computers. Some guidelines are also tabulated for designing a reuse facility that allows users to take advantage of their previous transaction history. The second section corroborates these principles by a post hoc study of user traces obtained from another quite different command line system. The final section steps back from the empirical findings and presents a broader view of reuse.

Principles and guidelines

This section abstracts empirical principles governing how people repeat their activities from the UNIX study described earlier. They are summarized and reformulated in Table 7.1 as empirically based general guidelines for the design of reuse facilities. Although there is no guarantee that these guidelines generalize to all recurrent systems, they do provide a more principled design approach than uninformed intuition.

Principles: how users repeat their activities

A substantial portion of each user's previous activities are repeated. In spite of the large number of options and arguments that could qualify a command, command lines in UNIX csh are repeated surprisingly often by all classes of users. On average, three out of every four command lines entered by the user have already appeared previously. UNIX is classified as a recurrent system by the definition in Section 5.1.

Introduction

In this chapter, we will be putting the results we proved in Chapter 6 to work. We will develop algorithms to solve a variety of optimization problems, all important in their own right.

The first is to minimize the cost of a network joining together several nodes. This can always be achieved by using what is called a ‘greedy algorithm’.

Another problem is to find the distance between any two nodes along a given network, say a road network. Two simple iterative algorithms exist for this problem. A related problem is to find the path of longest length between two vertices of an acyclic directed graph. This arises in certain types of sequencing problems, where the edges represent elapsed times. We shall see that one of our algorithms for shortest paths can easily be adapted to solve this problem.

A different type of problem is exemplified by the construction of a timetable, given simple compatibility constraints. We can model this by colouring the vertices of a graph, but the best we can achieve is a heuristic algorithm, not optimal but just reasonably efficient.

We should note that Warshall's algorithm can also be interpreted as a graphical algorithm to calculate strong components, but that was treated when we studied transitive closures.

Implementations of these algorithms in Modula-2 can be found in the appendices.

Introduction

This chapter will introduce a far-reaching generalization of the concept of a function. Its definition will reflect the fact that it could be implemented on a computer by a list with two columns, one column with entries from one set, and the other column with entries from a second set. This is a simple example of a relational database.

The idea of a cartesian product of two sets introduced in Chapter 3 is a very powerful one, and will enable us to considerably extend the range of applications we can model.

If we can tabulate the direct dependencies, then we can find all of the indirect ones too, by chasing through chains of direct calls. To find the effect of a call of any procedure, we merely need to create a list or database of pairs of procedure names, listing (Proc_i, Proc_j) whenever Proc_i calls Proc_j. The list is as in Figure 4.1.

Computing was historically taught as a branch of mathematics, usually of applied mathematics if a distinction was made. This family union came to an end when computer science diverged from mere numerical calculations towards more general objects such as data records, parse trees, and also the theory of how a computer works. The emphasis has recently become more mathematical, but with a different sort of mathematics. Also, computer science has itself spawned its own offspring, in the shape of software engineering and information technology.

Mathematics departments accustomed to teaching first year single honours mathematics undergraduates normally teach them a course in continuous mathematics and one on abstract algebra, or linear algebra, or both. Computer scientists have been pressing for their first year to be taught mathematics which is more relevant to the current needs of that discipline, and, in particular, some discrete mathematics. The content of discrete mathematics is broadly similar to what used to be known as combinatorics, but also includes topics from the foundations of mathematics, such as logic and set theory.

This book is designed as a course in discrete mathematics for first year computer scientists or software engineers in universities and colleges of further education. The book should form the basis of a full, one year option of two lectures a week, either as a subsidiary course to computer science, or as part of a mathematics first year option, say replacing part or all of the algebra normally taught there.