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

This chapter initiates and serves as a preamble to a systematic discussion of several design paradigms. The concept of a paradigm is central, not only to this (the second) part of the book but also to the discussion of the relationship between design and science in Part III. It is, thus, of some importance to specify as exactly as possible what I mean when I use the terms ‘paradigm’ and ‘design paradigm’ in this work. The necessity for such clarification becomes specially urgent given the fact that in certain intellectual circles the word ‘paradigm’ has assumed the unfortunate status of a cult-word.

The present chapter also serves a second, less obvious, function. And that is, to demarcate the fundamentally descriptive spirit of the preceding chapters from the pronounced prescriptive character of the chapters to follow.

The discipline of design is necessarily Janus-faced. On the one hand the act of design is a cognitive and an intellectual process. Hence any theory of design must, at least in part, view design processes as natural processes that harness the capabilities inherent in, and are in turn harnessed to the limitations imposed by, human nature and intellect. A theory of design must at least in part be a cognitive theory and, therefore, descriptive in nature. Much of Part I was precisely that; in particular, the notion that design is an evolutionary phenomenon is a descriptive, empirical proposition – a consequence of the inherent bounds of our ability to make rational decisions.

INTRODUCTION

‘Classical’ design automation, of course, relied on the use of algorithms. That is, the earliest applications of computing techniques to design problem solving were all based on algorithms for producing designs. We may, therefore, refer to this approach as the algorithmic design paradigm.

A necessary (though not sufficient) condition for the algorithmic paradigm to be applicable is that the design problem be well-structured. Such problems are characterized by the fact that the requirements are all empirical in nature in the sense that one knows exactly how to determine whether or not a given design meets such requirements (see chapter 3, section 3.3). And although most interesting design problems are ill-structured many of their subproblems or components may turn out to be well-structured – in which case, the algorithmic paradigm may apply. Strictly speaking, then, one should think of the algorithmic paradigm as, so to speak, a tool that can be invoked by other more general paradigms such as TPD or even ASE to solve well-structured components of a given design problem.

COMPILING AS AN ALGORITHMIC STYLE

In the domain of computing systems design the algorithmic paradigm is perhaps most well represented by an important family of methods which may be collectively termed compiling. This is a technique or style which is ‘classical’ in that it was invented at a relatively early stage in the history of computer science; and it has been enormously successful as an instance of the algorithmic paradigm in the automation of software, firmware and hardware design.

THE SATISFICING NATURE OF DESIGN DECISIONS

In chapter 3 (section 3.4) I introduced the concept of bounded rationality. As noted there, bounded rationality is a model of rationality proposed by Simon (1976, 1982) that recognizes the severe limits on the cognitive and information processing capabilities of the decision making agent. Such limitations may arise in a variety of ways: the various factors or parameters affecting a decision may be so complex or they may interact in such complicated ways the agent may be unable to decide the best course of action; or the agent may simply not know all the alternative courses of action; or even when all the factors or alternatives are known fully, the cost of computing the best possible choice may be far too prohibitive.

Bounded rationality explains why design problems are so very often formulated in an incomplete manner (see section 3.4, chapter 3). But it has an even more profound consequence for the design process itself, and for the nature of design solutions.

Example 5.1

To understand this, consider a computer architect who has been given a particular set of initial requirements and is required to design a micro-architecture that meets these requirements. A computer's micro-architecture, it will be recalled (see foot-note 6, chapter 3) refers to the internal architecture of the computer as seen by the microprogrammer (see also Dasgupta 1989a, chapter 1).

We shall further assume that the initial requirements, though sparse, are quite precise and complete.

INTRODUCTION

Let us recapitulate some of the very basic features of the design process as articulated in Part I of this book.

1. (a) The requirements constituting the specification of a design problem may (initially) be neither precise nor complete; hence the elaboration of requirements becomes an integral part of the design process. Requirements may, furthermore, be of an empirical or a conceptual nature.

2. (b) A design is an abstract description of the target artifact that serves as a blueprint for implementation, and as a medium for criticism, experimentation and analysis.

3. (c) The designer is constantly faced with the problem of bounded rationality – the fact that designers and their clients are limited in their capacities to make fully rational decisions, or are limited in their ability to grasp the full implications of such decisions.

4. (d) Design decisions are more often than not satisficing procedures.

As a consequence of all of the above design can be naturally viewed as an evolutionary process possessing the following characteristics: at any stage of its development the design is viewed as a tentative or conjectural solution to the problem posed. The designer's task in each evolutionary cycle is to elaborate either the design or the requirements so as to establish or converge towards a fit between the two. Thus, an integral part of each evolutionary cycle is the critical testing of the ‘current’ design against the ‘current’ requirements (see chapter 5, especially section 5.3).

The natural point to begin any discussion of design is its definition – that is, to state succinctly in a single sentence what it is that one does when one designs and what the end product is. Such an enterprise has been attempted in a variety of contexts including architecture, engineering, computer science, and the hybrid discipline of computer-aided design. As might be expected these definitions range from the very prosaic to the very abstract and each reflects quite clearly the specific perspective, tradition, and bias of its author. Invariably, such attempts to capture an entire human (or more recently, human–computer) enterprise within the bounds of a single sentence are unsatisfactory at the very least and fail abysmally at the worst.

One reason why definitions fail is the ubiquity of design as a human activity. As Simon (1981) has pointed out, anyone who devises courses of action to change an existing state of affairs to a preferred one is involved in the act of design. We have all been involved in devising such courses of action; hence from the very experience of living – or at least from the very experience of purposively controlling our lives – we have an intuitive idea of what design is. Thus, any single all embracing definition leaves us dissatisfied as much by what it excludes as by what it contains. For every definition one can point to instances of what is intuitively or experientially felt to be design but which have been excluded from the definition.

Most design theorists including Simon (1981) and Jones (1980) among the more influential agree that, in an ultimate sense, the goal of design is to initiate change in some aspect of the world. We perceive an imperfection in the state of affairs in some specific domain and we conceive or design an artifact which when implemented will, we believe, correct or improve this state of affairs.

There are a number of consequences of this seemingly obvious observation.

DEMARCATING ENGINEERING FROM SCIENCE

I shall use the term engineering here (and throughout the book) as a synonym for the more cumbersome ‘sciences of the artificial’. That is, the term encompasses the activities involved in the production of all useful artifacts – both material, such as buildings, computers and machine tools, and symbolic or abstract such as organizations and computer programs. Clearly, except in the simplest of situations, engineering entails design.

The notion of design as an agent of change appears to establish a firm criterion for demarcating engineering from the natural sciences (such as physics, chemistry, biology or geology). According to conventional wisdom, the latter disciplines are concerned with understanding the natural universe; the engineering disciplines are concerned with its purposeful, artificial alteration or extension.

The tendency to distinguish between the natural sciences (or simply, ‘science’) and engineering has, over the years, assumed almost mythical proportions.

DESIGNS AS FORMAL ENTITIES

A formal system consists of a set of axioms – that is, formulas or assertions that are assumed or known to be true – and a set of inference or proof rules that allows one to make deductions. Given a formal system a formal proof of an assertion or formula F consists of a finite sequence of formulas

F1, F2, …, Fn = F

such that each Fi is deduced from Fi−1 (2 ≤ i ≤ n) using the set of axioms and the rules of inference. A formula F for which there exists a formal proof is called a theorem.

Let us suppose that the requirements R of a design problem and the design D itself are both representable within the common framework of a formal system. In that case the problem of demonstrating that D satisfies R – that there is a fit between D and R – can be addressed by the designer formally proving the assertion ‘D satisfies R’. The latter assertion becomes, in effect, a theorem.

The notion of treating designs as formal entities so that one may prove (or verify) their correctness with respect to a requirements set is at the heart of the formal design (FD) paradigm. This paradigm originated some two decades ago in seminal papers by Floyd (1967) and Hoare (1969) which together laid the foundations for proving the correctness of programs.