A user manual may provide instructions that, if the user follows them, achieve any of certain objectives as determined by the manual designers. A manual may therefore be viewed rather like a computer program, as pre-planned instructions. Accordingly, software engineering and its methods may be applied mutatis mutandis to the manual and its design process.

We consider structured programming methods, and show that some difficulties with user interfaces may be attributed to manuals being ‘unstructured’. Since there are many programming metrics, and very many styles of manuals for user interfaces, this paper is concerned with justifying the approach and showing how insightful it is.

Keywords: manuals, hypertext, multimedia, finite state machines, flowgraphs.

Introduction

There is much evidence that improved manuals improve user acceptance (Carroll, 1990). There is also the argument that improving manuals by changing the system documented by them leads to improved systems (Thimbleby, 1990). Thus manuals are an essential part of the system life cycle: from requirements and design, through usability, to acceptance.

The importance of manuals certainly extends beyond their use in training and reference. In some sense (whether this is explicit or implicit) a user must ‘know’ what they are doing to use a system, and the manual is a representation of what they could know. Whether a user could in practice verbalise their knowledge as a system manual is unlikely — it may not even be necessary to be able to do so if the system feedback is sufficient, cf. (Payne, 1991); however it is certain that, for many users, the manual is the prime input to their initial system knowledge.

Agents are becoming widespread in a variety of computer systems and domains, but often appear to have little in common with each other. In this paper we look at different agent systems and identify what a generic agent should be composed of. We also identify the characteristics of a task that make it worthy of an agentbased approach. We then discuss the implications for the interaction of using agents, that is, the notion of a balanced interface, and briefly look at how an agent-based approach assists in two very different application domains.

Keywords: agents, intelligent interfaces, groupwork, computer-supported cooperative work (CSCW).

Introduction

The term agent has become increasingly widespread over the past few years. Unfortunately, it has no consistent definition and means many different things to different people. This paper considers the multifarious uses that these disparate agents are put to and tries to identify what, if anything, they have in common. With this commonality in mind, we identify the general properties of an agent and consider what makes a task ‘agent worthy’.

Agent-based interaction has consequences, leading to the notion of a balanced interface. This leads on to a description of the design of a generic agent and a look at a couple of applications that are benefiting from being treated in an agent-based manner.

Classifying Agents

We can identify a number of categories that agents can be classified under, based on the functionality offered by the different types of agent.

The aim of the Previewing Information Operation (PIO) approach is to tackle some overhead factors imposed on the user-hypertext interaction. The purpose is to diminish cognitive overhead and disorientation problems by reducing some of their causes.

This paper describes an experiment carried out to evaluate the usability of the operations based on the PIO approach. Results from between-groups studies show that subjects' evaluation of the ease of use of the system and feeling of general orientation were affected by the presence of PIO operations. A further study has revealed that the PIO operations were predicted by standard navigational operations.

Keywords: hypertext, link selection, previewing information, evaluation.

Introduction

When referring to a user's interaction with a hypertext system, the metaphor generally used in the literature is that the user navigates or browses through the information by selecting those links which are interesting.

In such a scenario, an interactive session could be described as a sequence of link selections along with other navigational operations, as for instance backtracking and string searching. Each of the link selection operations performed is a very important unit of the navigation sequence the user goes through: without the link options and the navigation taking place by the user freely choosing among links, there is no hypertext.

Accordingly, the secondary navigational modes such as bookmarks, history lists, backtracking and search operations (Bernstein & Joyce, 1992), are probably as important as the link selection alternatives. Firstly, they promote the understanding of the embedded hypertext structure and the building of a cognitive map. Secondly, they help users orientate themselves when they are lost.

Software engineering requires the production of hierarchically organised text-based documents, such as specifications, source codes, and manuals. Folding editors are effective tools designed to support such activities involving documents of any complexity. In a collaborative work environment, especially in a large software development team, folding editors offer many advantages over the conventional editing system. Surprisingly, the use of folding editors has often been overlooked. This could partly be attributed to the generally inadequate design of their interface and partly to the lack of effective facilities available to support collaborative work.

This paper identifies some of the typical difficulties associated with sharing files in a software engineering teamwork environment and discusses the advantages of folding editors to overcome these problems. It then describes the rationale of a design of a user interface for folding editors to support collaborative work.

Keywords: folding editors, computer-supported cooperative work (CSCW), groupware, user interface design, software engineering, CASE tools, collaborative writing.

Introduction

Software development is an area of human activity requiring that people work together to solve a problem. Typically, teams of people are involved in the specification, design, implementation and testing of the many different modules that comprise a system under construction. Even though most tasks are assigned to one individual at any one time, many documents and program modules are written and maintained by multiple authors over the lifetime of the software project. Software engineering requires the production of hierarchically organised text-based documents, examples of which are: specifications, schedules, designs, programs, test plans, on-line help and manuals.

The use of formal system models in interface development is often criticised for failing to recognise the ‘human’ nature of interaction. This paper describes an abstract system model of interaction, termed the template model, which is designed to address this criticism (Roast, 1993). The template model relies upon the identification of template abstractions which are system components that have particular user significance. By employing template abstractions system properties can be linked closely to user requirements. Using this framework we describe two categories of system constraint that express general usability requirements output correctness and structural consistency.

The appropriateness of the perspective offered by the template model and the requirements expressed using it are illustrated in the analysis of an electronic mail system.

Keywords: formal methods, system modelling, interaction models, email.

Introduction

To ensure that interactive systems are used effectively it is accepted that intended users should have a central role in system development. From the point of view of system specification and development, this concern is met by normally requiring that a system and its operating environment be modelled. In the case of HCI, users of a system are the principal environment with which the system interacts. Hence ideally developers should consider modelling users in conjunction with the system being designed — for example see (Barnard & Harrison, 1989; Barnard & Harrison, 1992). In practice efforts to model system users have not provided sufficient accuracy and generality to reliably support software development. Commonly user models are used solely as evaluation mechanisms, and are not in a form that would relate to a design representation.

Executable task models are considered to hold promise for increasing the impact of task analysis upon software engineering. However, this approach generates a number of integration issues when user interface management systems (UIMS) are employed at run-time. A number of models of integration are proposed and critiqued, employing a task scenario which involves the customisation of a geographic information system. Some current UIMS are shown to militate against this integration on account of the dominance which is accorded to the application. Some current task representations are shown to pose integration problems on account of both their procedural nature, and neglect of the application. One organising theme of the paper is that of executable task models being considered as particular cases of knowledge-based systems.

Keywords: task analysis, user interface management systems, knowledge-based systems, geographic information systems, rapid prototyping, knowledge representation, formal methods, user modelling.

Introduction

A truism of software engineering for interactive systems is that development should ideally proceed from a requirements analysis, and should incorporate user requirements. Task analysis (TA) is frequently regarded as the most formal of available methods for addressing user requirements. However, it is also generally acknowledged that the lack of integration between TA and software engineering techniques has reduced the design impact of TA.

Recently, one promising development is executable task models, which take some task specification and generate a series of interaction screens (de Haan & van der Veer, 1992; Wilson et al., 1993). This approach has the advantage of demonstrating user requirements to the software developer in a concrete and unambiguous fashion. It may be distinguished from conventional rapid prototyping by the fact that the interaction is generated in a more principled fashion.

Recall from the past chapter (specifically, the section “Computation as metaphor for the exploration of creativity”) that what has been named the computational theory of scientific creativity or CTSC is a hypothesis about the nature of creativity (in the natural and the artificial sciences). This hypothesis is, furthermore, firmly rooted in the computational metaphor – more precisely, it relies on the formation of a metaphorical model connecting creative and computational processes.

It also bears repeating that this theory goes back to Newell, Shaw, and Simon (1962) and, in effect, is a special case of a broader theory of thinking known concisely as the physical symbol system hypothesis (Newell and Simon 1976). The theory also serves as the basis for some recent explanations, by Kulkarni and Simon (1988), Thagard and Nowak (1990), and Thagard (1988, 1990), of certain historically important discoveries in the natural sciences. Thus, the general nature of CTSC is well known and has been so for some time. The task of the present chapter is to articulate and state CTSC in a sufficiently precise form such that (1) the reader understands and can anticipate, at least in general terms, the direction along which the explanation of Wilkes's creativity will proceed in the chapters to follow (especially, in Chapters 4–6) and (2) it is posed as a genuinely testable (i.e., in principle, falsifiable) hypothesis for which the Wilkes case study constitutes a nontrivial test. The extent to which CTSC is, in fact, corroborated or refuted by this test, and the general lessons learned from the case study, are matters discussed in the final part of this book.

There we have it: an account – an explanation – of how a particular act of inventive design in the domain of one particular science of the artificial might have taken place. The explanation takes the form of a computation at the level of cognitive description known as the knowledge level. Just as the proof of a theorem stated as an organized, stepwise set of arguments is an explanation of why the theorem is (believed or should be believed by an individual or community to be) true, so also our explanation takes the form of a symbolic process – that is, a structured set of symbol-transforming actions. Extending this parallel further, just as a mathematical argument draws on a body of assertions (axioms, lemmas, and theorems) that are assumed or known to be true prior to the onset of the argument or are produced along the way, so also the process described in these pages appeals to a corpus of knowledge the tokens of which are in part postulated to have existed at the time Maurice Wilkes began to think about the problem and in part generated by the process itself.

Let us, at this stage, recall a point already emphasized in Chapters 1 and 4. Historical episodes of a certain type bear the stamp of contingency. Past episodes of cognitive acts such as the invention of a theory or the design of a new type of artifact belong to this category. Thus, any explanation of such an episode will inherit the burden of contingency. We can hardly ever claim that the episode must have happened in one particular way rather than some other.

In May 1949, the EDSAC computer, designed and constructed by Maurice Wilkes and his co-workers at the Cambridge University Mathematical Laboratory successfully performed its first, fully automatic computation (Wilkes, 1956, p. 39; 1985, p. 142; Wilkes and Renwick 1949). The machine was demonstrated soon after, in June 1949, at a conference entitled “High Speed Automatic Calculating Machines” held in Cambridge during which tables of squares and primes were printed out (Worsley 1949). As noted in chapter 1 (see the section “The invention of microprogramming: as a case study”), the EDSAC was the very first stored program computer to become fully operational.

The EDSAC was a serial machine in that (1) reading from or writing into main memory was done in a “bit-serial” manner – that is, each bit of a memory word was read or written into one at a time, and (2) the arithmetic unit performed its various operations in a bit-by-bit manner.

Soon after the EDSAC's completion, Wilkes became preoccupied with the issues of regularity and complexity in computer design. This preoccupation is documented not only in his retrospective writings (Wilkes 1985, pp. 184–5, 1986), but also in the early sections of Wilkes (1951), as a preamble to his description of the microprogramming principle. Thus, there is considerable evidence that the development of microprogramming was the outcome of the following problem:

Among the many features of the mind that humans have chosen to speculate on, few evoke a greater sense of enigma than creativity. Believing that as a cognitive act it stands well beyond the humdrum, we pay special homage to those whose occupations are thought to be intrinsically creative: artists, scientists, writers, musicians, and inventors. Recognizing further that even among them there are a few whose works are so very special and so far transcend the achievements of the rest, we accord them extra reverence; we often bestow on them the appellation “genius”; we wonder, sometimes in awe and not without a tinge of envy, about their mental makeup; and we ponder the nature of the process their minds have enacted in arriving at a particular poem, symphony, theory, or artifact.

We see evidence of this compelling interest in creativity in many distinct forms. The very best type of biography, for instance, embodies an engagement on the part of the biographer with his or her subject's life and work. The biographer's task is to comprehend how childhood, social background, worldview, intellectual influences, personal relationships, and so on may have affected, perhaps even serve as an explanation of, the subject's particular acts of creation. In Richard Ellman's (1982) biography of James Joyce, there is a chapter titled “The Backgrounds [sic] to ‘The Dead’” in which the main elements of this short story – its characters, the setting, even the basic plot – are explained or elucidated by Ellman in terms of Joyce's own background and experience.

This brings us to the end of this particular inquiry. We began with a central concern: the nature of creativity as it is manifested in the development or design of artifacts. Not all acts of design count as creative acts. Like ideas and theories about nature or works of literature and art, the creation of artifacts is deemed creative when the outcome is original in some sense. Drawing on a distinction made by Johnson-Laird (1988a), Boden (1991), and others, we saw that it is possible to establish criteria of originality either from the perspective of the individual agent or from that of the society or community to which the agent belongs. When the outcome of an act of design is an artifactual form that satisfies one or more of the criteria of originality, the design act is called inventive or creative design. More simply, we call it invention. Inventing artifactual forms corresponds to discovering laws or inventing theories about natural phenomena. Thus, it seemed reasonable to suppose that studies of creativity in the natural sciences might provide insight into the nature of creativity in the sciences of the artificial.

We saw that philosophy of science, having been primarily preoccupied with the logic of justification, had little to contribute to our inquiry. Fortunately, there has emerged in relatively recent times a new kind of inquiry into scientific activity that draws on the ideas of cognitive psychology, history of science, and artificial intelligence; it was to these sources we turned.

The main ingredients have now been assembled. We have, first, a computational theory of scientific creativity, CTSC. Its central thesis is that a cognitive act resulting in a scientific product – a solution to a scientific problem – deemed original by the originator or by the relevant scientific community can be specified as, or be explained in the form of, a knowledge-level process.

Second, we have a detailed account of the circumstances attending a particular episode from the arena of computer science: the invention of microprogramming. Since computer science is a science of the artificial, one can regard this invention as signifying the creation of a technological idea, the invention of a new artifactual form that satisfies certain functions or, more prosaically, as an instance of highly original design. In the artificial sciences, these views are virtually indistinguishable.

This historical account is as detailed as the documented evidence will allow. And viewed as a historical explanation, it would appear to be satisfactory. That is, to the question What were the circumstances attending Wilkes's invention of microprogramming? the narrative presented in Chapter 3 would constitute an explanation of the sort historians of science ordinarily produce. It identifies the state of affairs that existed regarding computers and computing circa 1950. It then presents the particular problem that exercised Wilkes (i.e., that of regularity and order in the design of the control unit) and describes, in terms of the known state of affairs (specifically with regard to the EDSAC), how or why the problem arose. The narrative then points out that Wilkes was led to the idea of the diode matrix in the EDSAC order interpreter.