I have known Ann for many years. Our paths have crossed and even at times overlapped. For example, I left the MRC Applied Psychology Unit, Cambridge, in 1979 to direct the Ergonomics Unit at UCL. Ann joined the APU in 1991 to work on the Amodeus Project with Phil Barnard,  Michael Harrison and others, with whom I continued to keep in contact. Along with Steve Cummaford, Ann and I presented a joint tutorial entitled: ‘Introduction to HCI Structured Engineering Design Methods’ at HCI ’02, which signaled a common interest in HCI Engineering.

I retired in 2001, to be replaced by Harold Thimbleby, who wisely brought Ann with him from Middlesex University. Ann, in turn, replaced Harold and directed UCLIC from 2004 to 2011. She and Alistair Sutcliffe endeared themselves to me for ever by editing the John Long Festschrift, even allowing me to contribute, which is unusual in festschrift circles. Indeed, it was the Festschrift, which gave me the idea for setting up <hciengineering.net>.

To complete the circle, I invited Ann to contribute to the Papers Section here and she kindly agreed. Even better, her paper continues the engineering theme of HCI, making an important contribution to the website. Indeed, the issues raised are so relevant, that, with Ann’s agreement, I have added a commentary of my own, in an attempt to bring the issues together and to take them forward by means of a listing of Requirements for engineering interactive computer systems. Thank you Ann – much appreciated.

Blandford’s paper is entirely concerned with Engineering. It is an important paper, as it raises critical issues, concerning ‘the nature of engineering for interactive computer systems’. The aim of this commentary is to suggest how these issues might be carried forward both generally and particularly in the form of Requirements for Engineering Interactive Computer Systems. The needs for such Requirements are identified in the comments and then listed separately.

Engineering, here, is presumably in contrast to the arts and to the sciences, which have their own different roles and values, if and when, relevant to interactive computer systems. The contrast is instructive for distinguishing engineering approaches from those of other disciplines or types of knowledge more generally.

Blandford, indeed, achieves the aim of ‘putting forward different cases for and against particular views of engineering in relation to interactive computer systems’. The question now arises as to how to bring these views together and how to take them forward. The listing of Requirements for engineering interactive computer systems, as proposed here, is one such way.

The reverse is presumably also the case, that anyone, who claims to be doing engineering, at the same time  claims to be an engineer. The latter case would seem to be more suited to the current engineering claims with respect to interactive computer systems.

No-one would question engineering’s application of scientific and mathematical principles, where the latter already exist and are appropriate. However, in their absence, or if they are not relevant, ‘practical knowledge’ can also be claimed to support engineering practices (Wikipedia, 2015), as in ‘craft engineering’. The latter can also be claimed to be ‘rigorous’, in that one craft engineer, or one type of craft engineering, might be said to be more rigorous than another.

Any approach to engineering interactive computer systems is required to specify the relationship between the explicit and the implicit knowledge used to support its practices.

Most definitions of engineering, following Blandford, suppose it to be used for ‘practical ends’ and to solve practical problems. Confirmation is also to be found elsewhere: ‘to find suitable solutions to problems’; ‘to make improvements to the status quo’ etc. (Wikipedia, 2015). Solving practical problems , then, is central to engineering, including diagnosis of the problem in the first place. In the absence of the diagnosis of a problem, it is unclear what can be meant by a solution (see also Comment 5 and Requirement 1).

Any approach to engineering interactive computer systems is required to specify the implicit and explicit engineering knowledge and practices used in the diagnosis of (engineering) problems and the prescription of (engineering) solutions.

Blandford is, of course, quite right to identify the importance of design for engineering interactive computer systems. However, other definitions suggest the need to include implementation/build/use/research/improve/ maintain or some such (Wikipedia, 2015). Here, engineering is considered to include at least both design and implementation – the latter term being adopted as already in general use, as concerns the development of interactive computer systems.

Any approach to engineering interactive computer systems is required to decompose engineering into its component practices, at least to a level commensurate with that of ‘design’.

The engineering criteria, cited by Blandford for the successful address of practical problems – that is, ‘consistency, usability, economy, and safety’ are uncontroversial. Additional criteria to be found in the literature are no more controversial: intended function; improvement of structures; economics of operation; performance as expected; efficiency etc. (Wikipedia, 2015). No limit appears to be placed on the criteria, although they are related, directly or indirectly, to the knowledge and practices of engineering. The criteria can be both absolute (units of interactive work performed within some time limit) or relative (more units of work performed than at present).

Any approach to engineering interactive computer systems is required to specify the performance  criteria, by which the developed system is to be judged (and validated – see also Comment 17 and Requirement 9). Engineering for performance  is central to any approach and implicates both design and implementation (see also Requirement 7).

There are many obvious differences , as pointed out by Blandford, between safety-critical systems and fun-, affect-, experience-systems. Both concern the issues of principles (or more generally knowledge and practices) and rigour (or more generally formality). Both these issues deserve more detailed development by the different approaches to engineering interactive computer systems.

Any approach to engineering interactive computer systems is required to specify the formal and the empirical nature of its knowledge and practices (and indeed, the type of problem they are able to diagnose and the type of solution they are able to prescribe) – see also Requirement 4.

Blandford correctly asserts that iterative testing is not particular to an engineering approach to developing interactive computer systems. However, iterative testing  currently makes an important contribution to the development of such systems.  Iterative testing may be an empirical means of making good some of the current deficit in formal engineering knowledge and practices. Empirical (and so rigour) might be usefully contrasted with formality. See also Comment 9.

Any approach to engineering interactive computer systems is required to specify the relationship between the formal and the empirical nature of its knowledge and practices (and, indeed, the type of problem they are able to diagnose and the type of solution they are able to prescribe). See also Comment 10.

Engineering involves not only design components of the development of interactive computer systems; but also implementation ones ( see also Comment 7 and Requirement 3).

Iteration, as identified by Blandford,  is indeed currently essential to the development of interactive computer systems (although not necessarily as a matter of principle). Empirical iterative knowledge and methods may be making good some of the deficit of formal (analytic) knowledge and methods. See also Comment 10.

The four main phases of interactive computer systems development, identified by Blandford and generally agreed within HCI are: requirements; design alternatives; prototype; and evaluation. Blandford considers that neither requirements gathering nor user testing are ‘particularly amenable to the application of scientific and mathematical principles, although both can be performed rigorously’. This is certainly the case at present and may indeed be the case in the longer term and even ultimately; but until the notion of principles is more clearly specified and developed, including its formality, it may be better to leave the matter open at this time. Perhaps that is the thrust of Blandford’s ‘ not particularly amenable’.

Any approach to engineering interactive systems is required to specify the different types of knowledge (for example: principles (both substantive and methodological)); guidelines; models etc), which support different sorts of design and implementation practices (for example: trial and error; specify then implement; prototype, test and iterate etc).

See Comment 8.

Blandford’s notion that certain aspects of interactive computers systems may be ‘softer’ than others (such as full user experience; context of use; and user conceptualisation of computer functionality) is an interesting one. The idea might be carried forward by relating it to engineering knowledge and practices and their problems and solutions. For example, ‘hard’ problems, which can be completely specified (for the purposes in hand), can be prescribed a solution by formal or empirical knowledge and practices. However, ‘soft’ problems, which cannot be completely specified (for the purposes in hand), can only be prescribed by empirical knowledge and practices. The hardness or softness of a problem and solution can only be determined empirically at this time (and maybe sometime into the future too).

Any approach to engineering interactive computer systems is required to specify the types of problem and solution, which it addresses, as well as their relationship with formal and empirical knowledge and practices. This requirement applies to both design and implementation.

It is worth noting, that following lay language usage, a problem can be said to exist, in the absence of a solution; but a solution can only be said to exist with respect to an actual or a possible problem. In addition, a problem can have many solutions and a solution can resolve many problems. Ignoring ‘softer’ interactive computer system aspects  might indeed produce a ‘a solution to the wrong practical problem’, as suggested by Blandford; but also might produce ‘a wrong solution to the right practical problem’. Neither is the right solution to the right problem, which is the aim of engineering.

Blandford is right to identify the importance of formal verification (although other types of verification may be possible). However, a pre-requisite to verification is derivation (or some such). In order to verify two representations, or whatever, both must be available and in a form, which can indeed be verified. This requirement holds for all products and representations involved in the engineering design and implementation processes. For example, for design (following Blandford): establishing requirements; prototypes; and conducting evaluations.

Any approach to engineering interactive computer systems is required to specify how its products and representations are both derived and verified and how the latter relate to the validation of both design and implementation.

Blandford is quite right to identify the importance of the validation, as well as the verification, of  interactive computer systems. Validation here cannot be less than evaluating to what extent, the interactive computer system , as designed and implemented, meets (or fails to meet) the user requirements, especially those of performance. Such an evaluation would involve the conceptualisation and operationalisation of the user requirements and their test against the interactive computer system, intended (that is, claimed) to meet them.

Any approach to engineering interactive computer systems is required to specify the processes by which the system is validated against its user requirements, especially those of performance, and their relationship with verification of both design and implementation.

Blandford draws an interesting distinction between a ‘narrower’ and a ‘broader’ view of software development. According to the narrower view, the engineering process makes the design (as conceived by others) ‘work’ and is the object of verification. According to the broader view, software development is iterative and includes usability, utility and user experience and is the object of validation. The question arises, as to the relationship between these two views and how that relationship is to be embodied in an engineering approach to interactive computer system development.

It is tempting to assign the responsibilities, associated with the narrower view, to software engineering, as implementation and the responsibilities, associated with the broader view to HCI, as design. However, the temptation is to be rejected. First, many interfaces, at this time, are designed (as well as implemented) by software engineers. Some of these engineers have had some HCI training; but others have not. Second, the recent development of interface tools  for design include de facto components of implementation. However, how and to whom narrow and broad responsibilities of design and implementation are to be assigned to both practitioners and researchers are critical for both professional and academic education/training matters.

Any approach to engineering interactive computer systems is required to specify the assignment of professional and academic responsibilities for verification (for example, property modelling; verification etc) and validation (for example, user requirements; context of use; user evaluation etc).