Close
Enter your
text here
Posts By :

John

3.2 General Conception of HCI Engineering Design Knowledge 150 150 John

3.2 General Conception of HCI Engineering Design Knowledge

The General Conception pre-supposes an associated HCI Engineering Discipline (F1) comprising: HCI Engineering knowledge, which distinguishes the interactive system of user and computer, the tasks it performs as desired and the goodness of that performance in terms of specific criteria (C1) The knowledge supports HCI Engineering practices seeking to solve design problems. Design problems here include specification, followed by implementation, of users interacting with computers (the interactive system) to perform tasks as desired in some domain of application. (C3)

The HCI Engineering Conception, then, is unequivocally one of design knowledge. (F2) HCI Engineering knowledge is the product of research. Such knowledge is public and ultimately formal. (F3) It may assume a number of forms, for example, codified, proceduralised, formal etc, as in theories, principles etc. It may be maintained in a number of ways; for example, it may be expressed in journals, learning systems, procedures, tools etc. HCI Engineering knowledge is, therefore, a necessary characteristic of the HCI Engineering Discipline. (C2)

The discipline of HCI Engineering, aims (in the longer term) to solve its general problem of design by the specification of designs before their implementation – as in ‘specify then implement’ design practices. (C6) (C7) (C9) The latter is made possible by the prescriptive nature of the knowledge supporting such practices – knowledge formulated as HCI Engineering principles. (C4) However, a pre-requisite for the formulation of any HCI Engineering principles is a Conception. The EU Conception, from which the HCI Engineering Conception is generalised, is a unitary view of the HCI Engineering design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. (F4) (C8) (C12)

Engineering principles are articulated in terms of those self-same concepts. The latter include: user; computer; interaction; task; domain of application; system; and performance (for a full listing – see 2.2). Thus, the Conception of HCI Engineering principles assumes the possibility of a codified, general, and testable formulation of HCI Engineering discipline knowledge. The latter might be prescriptively applied to designing humans and computers interacting to perform tasks as desired. Such principles would be unequivocally formal and operational. Indeed, their operational capability would derive directly from the formality of their concepts. (C4) HCI Engineering concepts would be generalisable over classes of design problem solutions. Since the principles are operational, their application (expressed as design solutions) would necessarily be specifiable. They would also be testable and so their reliability and generality could also be specified. (C5)

In this way would the principles, expressed in terms of the Conception of Engineering design knowledge, be validated. Such validated Engineering design principles would offer a better guarantee (that is, more assurance – see 3.6.1)) of solving the HCI general design problem. Better, for example, than the experiential trial-and-error knowledge of craft HCI or the guidelines/heuristics of Applied Science HCI. (C11) HCI Engineering principles, following the Conception of Engineering design knowledge, can be substantive or methodological. Methodological principles prescribe the methods for solving the general HCI design problem. Methodological principles would assure complete specification of all necessary levels of design solution representation. Substantive principles prescribe the features and properties of HCI systems that constitute solutions to the HCI Engineering design problem. (C10)

The extent, to which HCI engineering principles might be realiseable in practice, in the longer term, remains to be seen and demonstrated. In the meantime, craft knowledge (F5) in whatever form – models, methods, heuristics, guidelines, experience, procedures etc cannot be other than recruited to solve HCI design problems both by researchers and practitioners. (C13)

Key concepts are shown in bold on their first appearance only.

Footnotes and Citations

Footnotes

(F1) The contrast here with Engineering is Science, which has its own discipline problem, knowledge and practices.

(F2) See (F1)

(F3) For the present purposes, Engineering, in its early craft stages, is not addressed.

(F4) Other HCI Engineering conceptions, other than that of the EU, might, of course, also be postulated.

(F5) See (F3)

Citations

Long and Dowell (1989)

(C1) ‘The framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’. (Page 9, Lines 16-19)

(C2) ‘All definitions of disciplines make reference to discipline knowledge as the product of research or more generally of a field of study. Knowledge can be public (ultimately formal) or private (ultimately experiential). It may assume a number of forms; for example, it may be tacit, formal, experiential, codified – as in theories, laws and principles etc. It may also be maintained in a number of ways; for example, it may be expressed in journals, or learning systems, or it may only be embodied in procedures and tools. All disciplines would appear to have knowledge as a component (for example, scientific discipline knowledge, engineering discipline knowledge, medical discipline knowledge, etc). Knowledge, therefore, is a necessary characteristic of a discipline.’ (Page 11, Lines 30-38)

(C3) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation. It is able to do so because of the prescriptive nature of its discipline knowledge supporting those practices – knowledge formulated as engineering principles.’ (Page 24, Lines 11-14)

(C4) ‘The conception of HCI engineering principles assumes the possibility of a codified, general and testable formulation of HCI discipline knowledge which might be prescriptively applied to designing humans and computers interacting to perform work effectively. Such principles would be unequivocally formal and operational. Indeed their operational capability would derive directly from their formality, including the formality of their concepts.’ (Page 24, Lines 28-31)

(C5) ‘First, HCI engineering principles would be a generaliseable knowledge. …….. Second, engineering HCI principles would be operational, and so their application would be specifiable…….. Because they would be operational, they would be testable and their reliability and generality could be specified.’ (Page 27, Lines 20-22 and 36-28)

Dowell and Long (1989)

(C6) ‘The paper .….. examines the potential for Human Factors to formulate engineering principles. ……… A conception would provide the set of related concepts which both expressed the general design problem more formally, and which might be embodied in engineering principles.’ (Page 1513, Lines 9 and 10)

(C7) By comparing the HF general design problem with other, better-understood, general design problems, and by identifying the formal knowledge possessed by the corresponding disciplines, the potential for HF engineering principles is suggested.’ (Page 1514, Lines 15-18).

(C8) ‘However, a pre-requisite for the formulation of any engineering principle is a conception. A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. Engineering principles are articulated in terms of those concepts.’ (Page 1514, Lines 23-27)

(C9) ‘Generally, the established engineering disciplines possess formal knowledge: a corpus of operationalised, tested, and generalised principles. Those principles are prescriptive, enabling the complete specification of design solutions before those designs are implemented (see Dowell and Long, 1988b).’ (Page 1520, Lines 1-5)

(C10) ‘Engineering principles can be substantive or methodological. Methodological Principles prescribe the methods for solving a general design problem optimally. ……Methodological principles would assure each lower level of specification as being a complete representation of an immediately higher level. Substantive Principles prescribe the features and properties of artefacts, or systems that will constitute an optimal solution to a general design problem. (Page 1520, Lines 6-15)

(C11) ‘The contemporary HF discipline does not possess either methodological or substantive engineering principles. The heuristics it possesses are either ‘rules of thumb’ derived from experience or guidelines derived from psychological theories and findings. Neither guidelines nor rules of thumb offer assurance of their efficacy in any given instance, and particularly with regard to the effectiveness of a design. The methods and models of HF (as opposed to methodological and substantive principles) are similarly without such an assurance. (Page 1520, Lines 21-28)

(C12) ‘Such a conception ….. enables the formulation of engineering principles which embody and instantiate those concepts.( Page 1520, Line 1)

(C13) ‘The extent to which HF engineering principles might be realiseable in practice remains to be seen. It is not supposed that the development of effective systems will never require craft skills in some form, and engineering principles are not seen to be incompatible with craft knowledge, particularly with respect to their instantiation. At a minimum, engineering principles might be expected to augment the craft knowledge of HF professionals. Yet the great potential of HF engineering principles for the effectiveness of the discipline demands serious consideration.’ (Page 1533, Lines 24-29)

3.3 HCI/E(U) Conception of HCI Engineering Design Knowledge 150 150 John

3.3 HCI/E(U) Conception of HCI Engineering Design Knowledge

The HCI/E(U) Conception of HCI Engineering Design Knowledge presupposes an associated HCI Engineering Discipline, comprising: HCI engineering knowledge, which distinguishes the interactive system of user and computer, the work it performs and the effectiveness of that performance, in terms of task quality and system resource costs. This HCI design knowledge supports HCI practices seeking to diagnose design problems and to prescribe design solutions to those problems. (C18)

The EU Conception of the HCI Engineering design problem is informally expressed as: to design human interactions with computers for effective working. The EU Conception, then, is unequivocally one of design knowledge. HCI Engineering knowledge, following the EU Conception, is the product of research. Such knowledge is public and ultimately formal. It may assume a number of forms, for example, codified, proceduralised, formal etc, as in theories, principles etc. It may be maintained in a number of ways, for example, it may be expressed in journals, learning systems, procedures, tools etc. HCI Engineering knowledge is, therefore, a necessary characteristic of the EU HCI Engineering Discipline. (C3)

The discipline of HCI Engineering, aims, following the EU Conception, (in the longer term (F1)) to solve its general problem of design by the specification of designs before their implementation – as in ‘specify then implement’ design practices. (C12) (C19) The latter is made possible by the prescriptive nature of the knowledge supporting such practices – knowledge formulated as HCI Engineering principles. (C21)

However, a pre-requisite for the formulation of any HCI Engineering principles is a Conception. The EU Conception is a unitary view of the HCI Engineering design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. (C17) Engineering principles are articulated in terms of those self-same concepts. The latter include: user; computer; interaction; work; work domain; worksystem; effectiveness; performance; task quality; system resource costs etc (see 2.5 for a complete presentation of the EU design problem concepts, which would be recruited to the formulation of EU-conceived engineering principles. (C16) (C17) (F2)

Thus, the EU Conception of HCI Engineering principles assumes the possibility of a codified, general, and testable formulation of HCI Engineering discipline knowledge. The latter might be prescriptively applied to designing humans and computers interacting to perform work effectively. Such principles would be unequivocally formal and operational. Indeed, their operational capability would derive directly from the formality of their concepts. (C13) EU HCI Engineering concepts would be generalisable over classes of design problem solutions. Since the principles are operational, their application (expressed as design solutions) would necessarily be specifiable. They would also be testable and so their reliability and generality could also be specified. (C14)

In this way would the principles, expressed in terms of the EU Conception of Engineering design knowledge, be validated. Such validated Engineering design principles would offer a better guarantee (that is, more assurance) of solving the HCI general design problem. Better, for example, than the experiential trial-and-error knowledge of craft HCI (C4) (C5) (C6) or the guidelines/heuristics of Applied Science HCI (C7) (C8) (C9) (C10) (C11) (C15) (F3) HCI Engineering principles, following the EU Conception of Engineering design knowledge, can be substantive or methodological. Methodological principles prescribe the methods for solving the general HCI design problem. Methodological principles would assure complete specification of all necessary levels of design solution representation. Substantive principles prescribe the features and properties of HCI systems that constitute solutions to the EU HCI Engineering design problem. (C20)

The extent, to which HCI engineering principles might be realisable in practice, in the longer term, remains to be seen and demonstrated. In the meantime, craft knowledge in whatever form – models, methods, heuristics, guidelines, experience, procedures etc cannot be other than be recruited to solve HCI design problems both by researchers and practitioners (C22) (F4)

Key concepts are shown in bold on their first appearance only.

Footnotes and Citations

Footnotes

 (F1) In the shorter term, to solve HCI design problems, either for research or for practice, any type of knowledge might be used.
(F2) Or indeed to other types of Engineering knowledge, for example, models and methods, intended to support the diagnosis of design problems and the prescription of their design solutions.
(F3) Craft HCI would also include craft engineering HCI – see also (F1) and (F2).
(F4) See also (F1), (F2) and (F3).
Citations
Long and Dowell (1989)

(C1) ‘The framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’. (Page 9, Lines 16-19)

(C2) ‘ Some would claim HCI theory as explanatory laws, others as design principles. Some would claim HCI theory as directly supporting HCI practice, others as indirectly providing support. Some would claim HCI theory as effectively supporting HCI practice, whilst others may claim such support as non-existent.’ (Page 10, Lines 12-17)

(C3) ‘All definitions of disciplines make reference to discipline knowledge as the product of research or more generally of a field of study. Knowledge can be public (ultimately formal) or private (ultimately experiential). It may assume a number of forms; for example, it may be tacit, formal, experiential, codified – as in theories, laws and principles etc. It may also be maintained in a number of ways; for example, it may be expressed in journals, or learning systems, or it may only be embodied in procedures and tools. All disciplines would appear to have knowledge as a component (for example, scientific discipline knowledge, engineering discipline knowledge, medical discipline knowledge, etc). Knowledge, therefore, is a necessary characteristic of a discipline.’ (Page 11, Lines 30-38)

(C4) ‘Craft disciplines solve the general problems they address by practices of implementation and evaluation. Their practices are supported by knowledge typically in the form of heuristics; heuristics are implicit (as in the procedures of good practice) and informal (as in the advice provided by one craftsperson to another). Craft knowledge is acquired by practice and example, and so is experiential; it is neither explicit nor formal.’ (Page 16, Lines 4-8)

(C5) ‘…….. the (public) knowledge possessed by HCI as a craft discipline is not operational. That is to say, because it is either implicit or informal, it cannot be directly applied by those who are not associated with the generation of the heuristics or exposed to their use. If the heuristics are implicit in practice, they can be applied by others only by means of example practice. If the heuristics are informal, they can be applied only with the help of guidance from a successful practitioner (or by additional, but unvalidated, reasoning by the user).’ (Page 18, Lines 28-33)

(C6) ‘If craft knowledge is not testable, then neither is it likely to be generalisable ……To be clear, if being operational demands that (public) discipline knowledge can be directly applied by others than those who generated the knowledge, then being general demands that the knowledge be guaranteed to be appropriate in instances other than those in which it was generated. Yet, the knowledge possessed by HCI as a craft discipline applies only to those problems already addressed by its practice, that is, in the instances, in which it was generated.’ (Page 19, Lines 11 and 15-20)

(C7) ‘The discipline of science uses scientific knowledge (in the form of theories, models, laws, truth propositions, hypotheses, etc.) to support the scientific practice ……..Scientific knowledge is explicit and formal, operational, testable and generalisable. It is therefore refutable (if not proveable, Popper [1959])’. (Page 20, Lines 2-3 and 7-9)

(C8) ‘An applied science discipline is one which recruits scientific knowledge to the practice of solving its general problem – a design problem.’ (Page 20, Lines 16 and 17)

(C9) ‘ First, its science knowledge cannot be applied directly, not – as in the case of craft knowledge – because it is implicit or informal, but because the knowledge is not prescriptive; it is only explanatory and predictive. Its scope is not that of the general problem of design.’ (Page 23, Lines 20-23)

(C10) ‘Second, the guidelines based on the science knowledge, which are not predictive but prescriptive, are not defined, operationalised, tested or generalised with respect to desired effective performance. Their selection and application in any system would be a matter of heuristics (and so paradoxically of good practice).’ (Page 23, Lines 25-28)

(C11) ‘Science knowledge is explicit and formal, and so supports reasoning about the derivation of guidelines, their solution and application (although one might have to be a discipline specialist so to do).’ (Page 23, Lines 36-38)

(C12) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation. It is able to do so because of the prescriptive nature of its discipline knowledge supporting those practices – knowledge formulated as engineering principles.’ (Page 24, Lines 11-14)

(C13) ‘The conception of HCI engineering principles assumes the possibility of a codified, general and testable formulation of HCI discipline knowledge which might be prescriptively applied to designing humans and computers interacting to perform work effectively. Such principles would be unequivocally formal and operational. Indeed their operational capability would derive directly from their formality, including the formality of their concepts.’ (Page 24, Lines 28-31)

(C14) ‘First, HCI engineering principles would be a generaliseable knowledge. …….. Second, engineering HCI principles would be operational, and so their application would be specifiable…….. Because they would be operational, they would be testable and their reliability and generality could be specified.’ (Page 27, Lines 20-22 and 36-28)

(C15) ‘ Although all three conceptions address the general problem of HCI, they differ concerning the knowledge recruited to solve the problem. Craft recruits heuristics; applied science recruits theories expressed as guidelines; and engineering recruits principles.’ (Page 28, Lines 22-24)

Dowell and Long (1989)

(C16) ‘The paper ….. examines the potential for Human Factors to formulate engineering principles. ……… A conception would provide the set of related concepts which both expressed the general design problem more formally, and which might be embodied in engineering principles.’ (Page 1513, Lines 9 and 10)

(C17) ‘However, a pre-requisite for the formulation of any engineering principle is a conception. A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. Engineering principles are articulated in terms of those concepts.’ (Page 1514, Lines 23-27)

(C18) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 43-45)

(C19) ‘Generally, the established engineering disciplines possess formal knowledge: a corpus of operationalised, tested, and generalised principles. Those principles are prescriptive, enabling the complete specification of design solutions before those designs are implemented (see Dowell and Long, 1988b). This theme of prescription in design is central to the thesis offered here.’ (Page 1520, Lines 1-5)

(C20) ‘Engineering principles can be substantive or methodological. Methodological Principles prescribe the methods for solving a general design problem optimally. ….. Methodological principles would assure each lower level of specification as being a complete representation of an immediately higher level. Substantive Principles prescribe the features and properties of artefacts, or systems that will constitute an optimal solution to a general design problem. (Page 1520, Lines 6-15)

(C21) ‘Such a conception ….. enables the formulation of engineering principles which embody and instantiate those concepts. ( Page 1520, Line 46 and Page 1521, Line 1)

(C22) ‘The extent to which HF engineering principles might be realiseable in practice remains to be seen. It is not supposed that the development of effective systems will never require craft skills in some form, and engineering principles are not seen to be incompatible with craft knowledge, particularly with respect to their instantiation. At a minimum, engineering principles might be expected to augment the craft knowledge of HF professionals. Yet the great potential of HF engineering principles for the effectiveness of the discipline demands serious consideration.’ (Page 1533, Lines 24-29)

 

1.1 General Conception of HCI Discipline 150 150 John

1.1 General Conception of HCI Discipline

The General Conception of the HCI Discipline  is generalised from the General Conception of the HCI Engineering Discipline . The General Conception comprises HCI knowledge, which  takes a variety of forms , distinguishing the interactive system of people  and computers, what it does and how well it does it.  The knowledge supports HCI practices of design and implementation of people using  computers to do something as wanted. This Conception is general  to any approach to HCI.

 

Key Concepts, Footnotes and Citations

The General Conception (F1) of the HCI Discipline (C1) is generalised from the General Conception of the HCI Engineering Discipline (1.2). The General Conception comprises HCI knowledge, which  takes a variety of forms (F2), distinguishing the interactive system of people  and computers, what it does and how well it does it. (C2) The knowledge supports HCI practices of design (F3) and implementation of people using  computers to do something as wanted. (C3) This Conception is general  to any approach to HCI.

Key concepts are shown in bold on their first appearance only.

Footnotes

(F1) ‘Conception’ is preferred here, as it clearly implies a set of linked concepts, which is what a conception is. However, within HCI more generally , ‘Framework’ would do as well.  Some might even prefer ‘Model’ or most generally ‘Approach’.

(F2) Such forms of knowledge include: guidelines; models; methods; heuristics etc.

(F3) Design here includes evaluation.

Citations

 Long and Dowell (1989)

(C1) ‘The framework expresses the essential characteristics of the HCI discipline and can be summarised as ‘ the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’. (Page 9, Abstract, Lines 11-14)

(C2) ‘Second, the scope of the general problem of HCI is defined by reference to humans, computers, and the work they perform.’ (Page 9, Abstract, Lines 7-9)

(C3) ‘Most definitions assume three primary characteristics of disciplines: knowledge; practice; and a general problem.’ (Page 11, Lines 26 and 27)

1.2 General Conception of HCI Engineering Discipline 150 150 John

1.2 General Conception of HCI Engineering Discipline

The General Conception of the HCI Engineering Discipline is generalised from the HCI/E Conception . The General Conception comprises HCI Engineering Knowledge, which distinguishes the interactive system of user and computer, the tasks it performs as desired and the goodness of that performance in terms of specific criteria.  The knowledge supports Practices, seeking to solve design problems.  Design here includes specification, followed by implementation and evaluation of users interacting with computers (the interactive system), to perform tasks as desired in some domain of application.

Key Concepts, Footnotes and Citations

The General Conception of the HCI Engineering Discipline is generalised from the HCI/E Conception (1.3). The General Conception comprises HCI Engineering Knowledge, which distinguishes the interactive system of user and computer, the tasks (F1) it performs as desired and the goodness of that performance in terms of specific criteria. (F2) (C1)  The knowledge supports HCI Engineering Practices, seeking to solve design problems. (C2) Design here includes specification, followed by implementation, of users interacting with computers ( the interactive system), to perform tasks as desired in some domain of application. (C3)

Key concepts are shown in bold on their first appearance only.

Footnotes

(F1) Task here is to be interpreted widely, as anything a user can do with a computer, either desired or undesired, well or badly.

(F2 ) Criteria, here, may include: time; errors; completeness etc.

Citations

Long and Dowell (1989)

(C1) ‘It (the Conception) dichotomises ‘interactive worksystems’ which perform work, and ‘domains of application’ in which work originates, is performed, and has its consequences’. (Page 24, Lines 39 and 40)

(C2) ‘The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design.’  (Page 12, Lines 3-5)

(C3) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation.’ (Page 24, Lines 11-12).

 

1.3 HCI/E Conception of HCI Engineering Discipline: a Summary 150 150 John

1.3 HCI/E Conception of HCI Engineering Discipline: a Summary

The HCI/E Conception of HCI as an Engineering discipline is a summary of the complete version (1.4 and 1.5).

The Conception comprises: HCI Engineering Knowledge as Principles, which distinguish the interactive worksystem, of user and computer, the work it performs and the effectiveness of that performance in terms of task quality and system resource costs. These Principles support HCI Engineering Practices seeking to diagnose design problems and to prescribe design solutions to those problems. Design here is characterised as ‘specify then implement’ designs of users interacting with computers (the interactive worksystem) to perform effective work in some domain of application.

Key concepts, Footnotes and Citations

The HCI/E Conception of the HCI Engineering Discipline comprises (C2): HCI Knowledge as Principles (F1), which distinguish the interactive worksystem, of user and computer, the work it performs and the effectiveness of that performance in terms of task quality and system resource costs. (C3) These Principles support HCI Practices seeking to diagnose design problems and to prescribe design solutions to those problems. (F2) (C1) Design here is characterised as ‘specify then implement’ designs of users interacting with computers (the interactive worksystem) to perform effective work in some domain of application. (F3) (C4)

Key concepts are shown in bold on their first appearance only.

 Footnotes

 (F1) No such Principles exist in the current research and practice of HCI. The HCI/E Conception and frameworks are intended to form the basis, on which such Principles might be constructed in the longer term. A start, however, has been made (Stork (1999) and Cummaford (2007). In the meantime, HCI/E research and practice recruits whatever HCI knowledge is available at present to solve design problems.

(F2) According to the HCI/E Conception, design problems have to be diagnosed (and specified) before they can be solved (and implemented).

(F3) The current absence of HCI Engineering Design Principles, requiring the use of different types of HCI knowledge – see (F1) above –   also requires, in the meantime,  they support different types of practice, for example, ‘trial-and- error; ‘specify and implement’; ‘prototype and test’ etc.

Citations

 Long and Dowell (1989)

(C1) ‘The  (discipline) framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’.’ (Page 9, Lines 16-19).

(C2) ‘Two prerequisites of a framework for conceptions of the HCI discipline are assumed. The first is a definition of disciplines appropriate for the expression of HCI. The second is a definition of the province of concern of the HCI discipline which, whilst broad enough to include all disparate aspects, enables the discipline’s boundaries to be identified.’ (Page 11, Lines 18-21).

(C4) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation. It is able to do so because of the prescriptive nature of its discipline knowledge supporting those practices – knowledge formulated as engineering principles.’ (Page 24, Lines 11-14)

Dowell and Long (1989)

(C3) ‘Taken together, the dimension of problem hardness, characterising general design problems, and the dimension of specification completeness, characterising discipline practices, constitute a classification space for design disciplines……..’ (Page 1518, Lines 20-22)

 

1.6 Discipline; Engineering; and Human-Computer Interaction 150 150 John

1.6 Discipline; Engineering; and Human-Computer Interaction

1.6.1 Discipline

The general concept of a discipline (F1) comprises: discipline knowledge (C3); practices (C4); and a general problem (C5), having a particular scope.(F2) (C1) (C2) The knowledge supports practices, seeking solutions to the general discipline problem, expressed in terms of its particular scope. (C6) (C7)

Footnotes and Citations

Footnotes

(F1) A discipline here is to be distinguished from the community, which practises it.

(F2) The scope of a problem is the domain or range over which it operates.

Citations

Long and Dowell (1989)

(C1) ‘First, consideration of disciplines in general suggests their complete definition can be summarised as: ‘knowledge, practices and a general problem having a particular scope, where knowledge supports practices seeking solutions to the general problem’.’ (Page 9, Lines 9-14)

(C2) ‘Most definitions assume three primary characteristics of disciplines: knowledge; practice; and a general problem.’ (Page 11, Lines 27 and 28)

(C3) ‘All definitions of disciplines make reference to discipline knowledge as the product of research or more generally of a field of study……. Knowledge, therefore, is a necessary characteristic of a discipline.’ (Page 11, Lines 29 and 30)

(C4) ‘Consideration of different disciplines suggests that practice is also a necessary characteristic of a discipline.’ (Page 11, Line 38 and Page 12, Line 1)

(C5) ‘Further, a discipline’s knowledge is used by its practices to solve a general (discipline) problem……’ (Page 12, Lines 1 and 2)

(C6) ‘Clearly, disciplines are here being distinguished by the general (discipline) problem they address.’ (Page 12, Lines 8 and 9)

(C7) ‘Taken together, the three necessary characteristics of a discipline (and the two basic properties additionally concluded), suggest the definition of a discipline as: ‘the use of knowledge to support practices seeking solutions to a general problem having a particular scope’.’  (Page 12, Lines 26-32)

1.6.2 Engineering

The general concept of a discipline of Engineering (F1) comprises: engineering knowledge, as principles (F2) (C2); their application to practices, seeking the diagnosis of, and the solution to, the general engineering problem of the design of particular systems or artefacts. (C1) This concept holds for any engineering approach to a discipline of HCI.

Footnotes and Citations

Footnotes

(F1) Engineering here is to be contrasted, for example, with Science.

(F2) Although Principles are critical to engineering knowledge, in contrast to other disciplines, it comprises a wide range of different types of knowledge – models; methods; etc.

Citations

Long and Dowell (1989)

(C1)’The discipline of engineering includes the engineering practice addressing the general (engineering) problem of design.’  (Page 12, Lines 3-5)

(C2) ‘The discipline of engineering may characteristically solve its general problem (of design) by the specification of designs before their implementation. It is able to do so because of the prescriptive nature of its discipline knowledge supporting those practices – knowledge formulated as engineering principles.’ (Page 24, Lines 11-14)

 

1.6.3 Human-Computer Interaction

The general concept of a discipline of HCI (C2) comprises: HCI knowledge; its application to practices, seeking solution to the general HCI problem (C4) of design, having the particular scope of people using (F1) computers to do something (F2) as wanted. (F3) (C1) (C3)

Footnotes and Citations

Footnotes

(F1) ‘Using’ here contrasts with simply ‘interacting.

(F2) ‘Something’ here is intentionally very general. The contrast is, again, with simply ‘interacting’ – see (F1).

(F3) ‘As wanted’ by, for example, the user; the client; the users’ organisation; or indeed all of them (and more).

Citations

Long and Dowell (1989)

(C1) ‘The  (discipline) framework expresses the essential characteristics of the HCI discipline, and can be summarised as: ‘the use of HCI knowledge to support practices seeking solutions to the general problem of HCI’.’ (Page 9, Lines 16-19).

(C2) ‘HCI concerns humans and computers interacting to perform work.’ (Page 13, Line 1)

(C3) ‘Taken together, these implications suggest a definition of the scope of the general (discipline) problem of HCI. It is expressed, in summary, as ‘humans and computers interacting to perform work effectively’.’ ( Page 13, Lines 10-12). (C4) … the general problem addressed by the discipline of HCI is asserted as: ‘the design of humans and computers interacting to perform work effectively’.  (Page 13, lines 19-21).

 

2.1 General Conception of HCI Design Problem 150 150 John

2.1 General Conception of HCI Design Problem

 The General Conception of the HCI design problem is expressed as: ‘to design people’s use of computers to do something as wanted.’ (C1) (C2) The General Conception of the HCI design problem presupposes an associated HCI Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The Conception belongs to the class of general design problem. (C4)

The General Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI. (C5) The scope includes: people, both as individuals, groups and as social organisations. It also includes computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines. Its scope also includes: the use of computers as wanted, both as concerns individuals and the organisations in which it occurs. (C6) (F1)

The Conception categorises HCI design problems as ‘easy’ or ‘difficult’. Easy and difficult problems are distinguished by the need for design solutions (as specified by HCI design practices) to be determinate. The design practices vary in the completeness of their specification before implementation. (C7) ‘Specify then implement’ design practices implicate more complete specification. ‘Implement and test’ design practices implicate less complete specification. (F2) Taken together, the dimension of problem difficulty, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for all approaches to HCI.

The General Conception of the HCI design problem asserts a basic distinction between people-computer systems, which do things as wanted and a world in which these things originate, are done and have their consequences. (C10) ‘As wanted’ relates to the relationship of an interactive system with its use, assimilating both whether things are done, as wanted and the effort required for that doing. (F3)  The concern of the associated HCI discipline is to design the interactive system to do things, as wanted. The interactive system consists of people using computers and computers being used. According to the Conception, the general problem of HCI is to produce designs of people, which, interacting with computers, do something, as wanted. (C9)

The interactions take place in a world in which computers are used to do things, which change that world in some way. (C10) Computer use by people arises at the intersection of organisations and computer technology. Conceptualisation thereof may be both abstract and physical.  The abstract conceptualisation includes information and knowledge. The physical conceptualisation includes things. Computer use produces changes in the world over time. Following the General Conception, organisations have domains as their operational scope and require the changes brought about by computer use. It is a requirement satisfied by people using computers as wanted. (C11) An HCI design problem exists, when actual computer use is not as wanted.

The General Conception identifies interactive systems, consisting of people and computers doing something as wanted. (C14) People formulate goals which are intentional (or purposeful). Computers are designed to achieve goals and are said to be intended (or purposive).  Computer use is distinguished by a boundary, enclosing all people and computers, whose purpose is to achieve a common goal. (C13) Interactive systems achieve goals by doing something as wanted, that is, by producing change.

People and computers are conceptualised as sub-systems, which interact. (C14) Interaction may be loosely understood as ‘what the person and computer do’ in contrast with ‘what is done’, that is, the changes effected in the domain of application. In the General Conception, interactions are both physical and abstract. (C15) The latter process information. (C17) In the General Conception of the HCI design problem, doing things as wanted derives from the relationship of an interactive system with its domain of application. ‘As wanted’ assimilates both how well things are done by the system and the efforts required by the doing. (F4) These are the primary constituents of the concept of performance. ‘As wanted’ performance of an interactive system is conceptualised such that as wanted might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C18) (F5)

Key concepts appear in bold on their first reference only.

Footnotes and Citations

Footnotes

 (F1) ‘As wanted’, here, may refer to individuals or groups, or indeed both, as in: users; clients etc.

(F2) ‘Implement and test’ design practices include, more generally, ‘trial and error’; ‘prototype and iterate (and test)’ practices etc.

(F3) ‘Effort’ is intended in no way to be restrictive. Different approaches have different concepts for what is required, for example, engagement; fun; experience, motivation etc.

(F4) See F3 above). (F5) Performance is not intended here to be restrictive. Different approaches to HCI have many different concepts, for example, efficiency; effectiveness; engagement; fun; experience etc.

Citations

 Dowell and Long (1989)

(C1) ‘…….. a conception of the general design problem …….. is expressed informally as: ‘to design human interactions with computers for effective working’.’  (Page 1513, Lines 12-13)

(C2) ‘A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts which can express that problem. Engineering principles are articulated in terms of those concepts. Hence, the requirement for a conception for the HF discipline is concluded (Section 1.5.).’ (Page 1514, Lines 19-22)

(C3) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 39-41)

(C4) ‘…….. one class of general problem is that of the general design problem and includes the design of artefacts (of bridges, for example) and the design of ‘states of the world’ (of public administration, for example).’ (Page 1524, Lines 43-45)

(C5)’…….. any general problem has the necessary property of a scope, delimiting the province of concern of the associated discipline.’ (Page 1514, Lines 47 and 48)

(C6) The scope of the HCI general design problem includes: humans, both as individuals, as groups, and as social organisations; computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines; and work, both with regard to individuals and the organisations in which it occurs. (Page 1515, Lines 11-14)

(C7) ‘A discipline’s practices construct solutions to its general design problem……..  disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs. ……..’ (Page 1517, Line 46; Page 1518, Lines 2 and 3).

(C8) ‘The interactive worksystem can be distinguished as two separate, but interacting sub-systems, that is, a system of human behaviours interacting with a system of computer behaviours.’ (Page 1523, Lines 1-3)

(C9) ‘The general design problem of HF then, is one of producing implementable specifications of human behaviours {U} which , interacting with computer behaviours {C}, are constituted within a worksystem {S} whose performance conforms with a desired performance (Pd).’ (Page 1523, Lines 11-14)

(C10) ‘The conception for HF identifies a world in which work originates, is performed and has its consequences. This section presents the concepts by which work and its relations with the user are expressed.’ (Page 1523, Lines 19 and 20)

(C11) ‘Organisations are conceptualised as having domains as their operational province ……..  It is a requirement satisfied through work.’ (Page 1524, Lines 36-38)

(C12) ‘The conception for HF identifies interactive worksystems consisting of human and computer behaviours together performing work.’ (Page 1526, Lines 2 and 3)

(C13) ‘Humans are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Computers, and machines more generally, are designed to achieve goals, and their corresponding behaviours are said to be intended (or purposive1). An interactive worksystem   (‘worksystem’) is a behavioural system distinguished by a boundary enclosing all human and computer behaviours whose purpose is to achieve and satisfy a common goal.’ (Page 1526, Lines 5-11)

(C14) ‘The behaviours of the human and computer are conceptualised as behavioural sub-systems of the worksystem – sub-systems which interact.’ (Page 1526, Lines 24 and 25)

(C15) ‘The behaviours constituting a worksystem are both physical as well as abstract.’ (Page 1526, Lines 39 and 40)

(C16) ‘Although the human and computer behaviours may be treated as separable sub-systems of the worksystem, those sub-systems extend a “mutual influence”, or interaction whose configuration principally determines the worksystem (Ashby, 1956).’ (Page 1527, Lines 24-27)

(C17) ‘The user may include both on-line and off-line human behaviours………’ (Page 1528, Lines 8 and 9) .

(C18) ‘A desired performance of an interactive worksystem may be conceptualised. Such a desired performance might either be absolute, or relative as in a comparative performance to be matched or improved upon.’ (Pages 1531. Lines 8-10)

(C19)……..’ Instances of the general design problem may include the development of a worksystem, or the utilisation of a worksystem within an organisation. Developing worksystems which are effective, and maintaining the effectiveness of worksystems within a changing organisational environment, are both expressed within the problem.’(Page 1532, Lines 16-20)

2.2 General Conception of HCI Engineering Design problem 150 150 John

2.2 General Conception of HCI Engineering Design problem

The Conception of the HCI Engineering (F1) general design problem is expressed informally as: ‘to design human interactions with computers to perform tasks effectively.’ (C1) The Engineering Conception is a unitary view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem (note: engineering knowledge would be expressed in terms of these concepts). (C2) (F2)

The Engineering Conception of the HCI design problem presupposes an associated HCI Engineering Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The Engineering Conception belongs to the class of general design problem and includes the design of artefacts (for example, bridges) and the design of states of the world (for example, public administration). (C4) The Engineering Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI Engineering. (C5) The scope includes: humans, both as individuals, groups and as social organisations. It also includes computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines. Its scope also includes: tasks, both as concerns individuals and the organisations in which it occurs. (C6) (F3)

The Engineering Conception categorises HCI Engineering design problems as ‘hard’ or ‘soft’. Hard and soft problems are distinguished by the need for engineering design solutions, as specified by HCI design practices, to be determinate. The design practices vary in the completeness of their specification before implementation. ‘Specify then implement’ design practices (based on formal design knowledge, such as principles) implicate more complete specification. ‘Implement and test’ design practices (based on informal design knowledge, such as guide-lines) implicate less complete specification. (C8) Taken together, the dimension of problem hardness, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for Engineering approaches to HCI. (C9)

The Engineering Conception of the HCI design problem asserts a fundamental distinction between behavioural systems, which perform tasks and a world in which tasks originate, are performed and have their consequences. (C13) Effectiveness derives from the relationship of an interactive system with its domain of application, assimilating both how well the tasks are performed by the system and the resources they consume. (C14) (F4) The concern of the associated HCI Engineering discipline is to design the interactive system for performance. (C15). The interactive system is constituted of two separate, but interacting sub-systems, that is, a system of human behaviours, interacting with a system of computer behaviours. (C16)

According to the Engineering Conception, the general design problem of HCI is to produce implementable designs of human behaviours, which, interacting with computer behaviours, are constituted within a system, whose performance conforms with some desired performance. (C17) The interactions take place in a world in which tasks originate and have their consequences. (C18) These tasks arise at the intersection of organisations and computer technology and require representation for the purposes of design. The tasks may be both abstract and physical.  The abstract representation of tasks includes information and knowledge. The physical representation includes energy and matter.  Different representations of tasks emerge at different levels of description. Representations may be related in two ways – at different levels of description and within those levels.  Tasks involve changes over time. Thus, representations of tasks exhibit an affordance for transformation, expressed by the ‘potential’ for change effected by tasks. A domain of application is conceptualised as: ‘a class of affordance of a class of representations of tasks’.

Following the Engineering Conception, organisations are conceived as having domains as their operational scope and requiring the realisation of the affordance of representations of tasks. It is a requirement satisfied by the performance of tasks. (C19) Organisations express their requirement for the performance of tasks by formulating goals. A product goal specifies a required change, realised by means of the performance of tasks.  A variance exists, if the required change differs from that specified by a product goal. An HCI Engineering design problem exists, when actual task performance is not equal to desired performance. (F5) The Engineering Conception identifies interactive systems, consisting of human and computer behaviours together performing tasks. (C20) Humans formulate goals and their corresponding behaviours are said to be intentional (or purposeful). Computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive).  An interactive system is a behavioural system distinguished by a boundary, enclosing all human and computer behaviours, whose purpose is to achieve a common goal. (C29) Interactive systems achieve goals by the performance of tasks, that is, by producing change. (C21)

The behaviors of the human and computer are conceptualised as behavioral sub-systems of the worksystem – sub-systems, which interact. (C22) Behavior may be loosely understood as ‘what the user does’ in contrast with ‘what is done’, that is, changes effected by tasks in the domain. More precisely, the user is conceptualised as a system of distinct, but related, human behaviours identifiable as the sequence of actions of a person interacting with a computer to perform tasks and corresponding with an intentional change in the domain. Although possible at many levels, the user must be at least conceptualised at a level commensurate with the level of description of the changes effected by tasks in the domain.

In the Engineering Conception, interactive system behaviours are both physical and abstract. (C23) The latter process information, concerning task changes in the domain, required by goals. Physical behaviours are related to abstract behaviors.  The user may include both on-line and off-line human behaviours. On-line behaviours are associated with the computer’s representation of the domain; 0ff-line behaviours are associated with non-computer representations of the domain or the latter itself. (C25)

Tasks performed by interactive systems consume its resources. Certain resources are associated both with the user and others with the computer. Such resources may be both mental and physical. (F6) In the Engineering Conception of the HCI design problem, effectiveness derives from the relationship of an interactive system with its domain. Effectiveness assimilates both how well the tasks are performed by the system and the resources consumed by it in so doing. These are the primary constituents of the concept of performance through which effectiveness is expressed. A desired performance of an interactive system is conceptualised such that desired performance might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C27)

This concludes the expression of the Engineering Conception of the HCI design problem. The Conception is a unitary view of the necessary concepts and their relations to express that design problem and so, any design solution.

Key concepts are shown in bold on their first appearance only.

Footnotes and Citations

Footnotes

(F1) Engineering here is contrasted, for example, with Science.

(F2) Engineering approaches may themselves vary, for example, depending on the type of knowledge they acquire and apply. However, the present conception is intended to be general to all engineering approaches.

(F3) The use of ‘task’ here is in no way restrictive. Tasks may be more-or-less well specified, according to the engineering approach in question.

(F4) ‘Resources’ may be variously conceptualized, for example, as: effort; affect; knowledge etc.

(F5) There are many different expressions of performance, for example: effectiveness; efficiency; time and errors; safety; expedition etc.

(F6) See F4 above.

Citations

 Dowell and Long (1989)

(C1) ‘…….. a conception of the general design problem …….. is expressed informally as: ‘to design human interactions with computers for effective working’.’  (Page 1513, Lines 12-13)

(C2) ‘A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts which can express that problem. Engineering principles are articulated in terms of those concepts. Hence, the requirement for a conception for the HF discipline is concluded (Section 1.5.).’ (Page 1514, Lines 19-22)

(C3) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 39-41)

(C4) ‘…….. one class of general problem is that of the general design problem and includes the design of artefacts (of bridges, for example) and the design of ‘states of the world’ (of public administration, for example).’ (Page 1524, Lines 43-45)

(C5)’…….. any general problem has the necessary property of a scope, delimiting the province of concern of the associated discipline.’ (Page 1514, Lines 47 and 48)

(C6) The scope of the HCI general design problem includes: humans, both as individuals, as groups, and as social organisations; computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines; and work, both with regard to individuals and the organisations in which it occurs. (Page 1515, Lines 11-14)

(C7) ‘…….. The ‘design’ disciplines are ranged according to the ‘hardness’ or ‘softness’ of their respective general design problems. …….. However, here hard and soft problems will be generally distinguished by their determinism for the purpose, that is, by the need for design solutions to be determinate.’ (Page 1517, Lines 31 and 32 and 38-40).

(C8) ‘A discipline’s practices construct solutions to its general design problem……..  disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs. ……..’ (Page 1517, Line 46; Page 1518, Lines 2 and 3).

(C9) ‘Taken together, the dimension of problem hardness, characterising general design problems, and the dimension of specification completeness, characterising discipline practices, constitute a classification space for design disciplines……..’ (Page 1518, Lines 20-22)

(C10) ‘First, a general relation may be apparent between the hardness of a general design problem and the realiseable completeness with which its solutions might be specified. (Page 1518, Lines 20-22)

(C11) ‘Whilst the realiseable completeness with which a discipline may specify design solutions is governed by the hardness of the general design problem, the actual completeness with which it does so is governed by the formality of the knowledge it possesses.’ (Page 1519, Lines 15-18)

(C12)’…….. there exists no pre-ordained relationship between the formality of a discipline’s knowledge and the hardness of its general design problem.’ (Page 1519, Lines 31-33)

(C13) ‘The conception for the (super-ordinate) engineering discipline of HCI asserts a fundamental distinction between behavioural systems which perform work, and a world in which work originates, is performed and has its consequences.’ (Page 1522, Lines 2-4)

(C14) ‘Effectiveness derives from the relationship of an interactive worksystem with its domain of application. ‘(Page 1522, Lines 9 and 10)

(C15) ‘The concern of an engineering HCI discipline would be the design of interactive worksystems for performance.’ (Page 1522, Lines 13 and 14)

(C16) ‘The interactive worksystem can be distinguished as two separate, but interacting sub-systems, that is, a system of human behaviours interacting with a system of computer behaviours.’ (Page 1523, Lines 1-3)

(C17) ‘The general design problem of HF then, is one of producing implementable specifications of human behaviours {U} which, interacting with computer behaviours {C}, are constituted within a worksystem {S} whose performance conforms with a desired performance (Pd).’ (Page 1523, Lines 11-14)

(C18) ‘The conception for HF identifies a world in which work originates, is performed and has its consequences. This section presents the concepts by which work and its relations with the user are expressed.’ (Page 1523, Lines 19 and 20)

(C19) ‘Organisations are conceptualised as having domains as their operational province ……..  It is a requirement satisfied through work.’ (Page 1524, Lines 36-38)

(C20) ‘The conception for HF identifies interactive worksystems consisting of human and computer behaviours together performing work.’ (Page 1526, Lines 2 and 3)

(C21) ‘Humans are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Computers, and machines more generally, are designed to achieve goals, and their corresponding behaviours are said to be intended (or purposive1). An interactive worksystem   (‘worksystem’) is a behavioural system distinguished by a boundary enclosing all human and computer behaviours whose purpose is to achieve and satisfy a common goal.’ (Page 1526, Lines 5-11)

(C22) ‘The behaviours of the human and computer are conceptualised as behavioural sub-systems of the worksystem – sub-systems which interact.’ (Page 1526, Lines 24 and 25)

(C23) ‘The behaviours constituting a worksystem are both physical as well as abstract.’ (Page 1526, Lines 39 and 40)

(C24) ‘Although the human and computer behaviours may be treated as separable sub-systems of the worksystem, those sub-systems extend a “mutual influence”, or interaction whose configuration principally determines the worksystem (Ashby, 1956).’ (Page 1527, Lines 24-27)

(C25) ‘The user may include both on-line and off-line human behaviours: on-line behaviours are associated with the computer’s representation of the domain; offline behaviours are associated with non-computer representations of the domain, or the domain itself.’ (Page 1528, Lines 8-11)

(C26) ‘Physical human structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes.’ (Page 1528, Lines 40 and 41)

(C27) ‘A desired performance of an interactive worksystem may be conceptualised. Such a desired performance might either be absolute, or relative as in a comparative performance to be matched or improved upon.’ (Pages 1531. Lines 8-10)

(C28)……..’ Instances of the general design problem may include the development of a worksystem, or the utilisation of a worksystem within an organisation. Developing worksystems which are effective, and maintaining the effectiveness of worksystems within a changing organisational environment, are both expressed within the problem.’(Page 1532, Lines 16-20)

2.3 HCI/E(U) Conception of HCI Engineering Design Problem: a Summary 150 150 John

2.3 HCI/E(U) Conception of HCI Engineering Design Problem: a Summary

The HCI/E(U) Conception of the HCI Engineering general design problem is expressed informally as: ‘to design human interactions with computers for effective working.’ (C1) The EU Conception is a unitary view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts, which can express that problem. Engineering knowledge, in the form of principles, would be expressed in terms of those same concepts). (C2) (F1)

The HCI/E(U) Conception of the HCI Engineering design problem presupposes an associated HCI Discipline having three primary characteristics: a general problem; practices providing solutions to that problem; and knowledge supporting those practices. (C3) The EU conception of the design problem belongs to the class of general design problem and includes the design of artefacts (for example, bridges) and the design of states of the world (for example, public administration). (C4)

The HCI/E(U) Conception has the necessary property of a scope, delimiting the province of concern of the associated discipline of HCI Engineering. (C5) The scope includes: humans, both as individuals, groups and as social organisations. It also includes computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines. Its scope also includes: work, both as concerns individuals and the organisations in which it occurs.

The HCI/E(U) Conception categorises HCI Engineering design problems as ‘hard’ or ‘soft’. Hard and soft problems are distinguished by the need for engineering design solutions, as specified by HCI design practices, to be determinate. The design practices vary in the completeness of their specification before implementation. ‘Specify then implement’ design practices (based on formal design knowledge, such as principles) implicate more complete specification. ‘Implement and test’ design practices (based on informal design knowledge, such as guide-lines) implicate less complete specification. (C8) (F2) Taken together, the dimension of problem hardness, characterising HCI general design problems and the dimension of specification completeness, characterising HCI practices, constitute a classification space for approaches to HCI engineering, of which EU engineering is one. (C9)

The HCI/E(U) Conception of the HCI Engineering design problem asserts a fundamental distinction between behavioural systems, which perform work and a world in which work originates, is performed and has its consequences. (C13)  Effectiveness derives from the relationship of an interactive worksystem with its domain of application, assimilating both the work performed by the worksystem and the costs it incurs. (C14) The concern of the associated HCI Engineering discipline is to design the interactive worksystem for performance. (C15). The interactive worksystem is constituted of two separate, but interacting sub-systems, that is, a system of human behaviours, interacting with a system of computer behaviours. (C16)

According to the HCI/E(U) Conception, the general design problem of HCI Engineering is to produce implementable designs of human behaviours, which, interacting with computer behaviours, are constituted within a worksystem, whose performance conforms with some desired performance. (C17) The interactions take place in a world in which work originates and has its consequences. (C18) This work arises at the intersection of organisations and computer technology and is expressed in terms of objects. The latter may be both abstract, as well as physical and are characterised by their attributes. (C19) Abstract attributes are of information and knowledge. Physical attributes are of energy and matter. The different attributes of an object emerge at different levels within a hierarchy of levels of complexity. (C20) Attributes of objects are related in two ways – at different levels of complexity and within those levels. (C21) Attributes have states, which change or are changed over time. Thus, objects exhibit an affordance for transformation, expressed by their attributes’ potential for change of state. (C22) A domain of application is conceptualised as: ‘a class of affordance of a class of objects’. (C23)

Following the HCI/E)U) Conception, organisations are conceived as having domains as their operational scope and requiring the realisation of the affordance of objects. It is a requirement satisfied by work. (C24) Organisations express their requirement for the transformation of objects by formulating goals. A product goal specifies a required transformation, realised by means of the affordance of objects. (C25) The concept of Quality describes the variance of an actual transform with that specified by a product goal. An EU HCI Engineering problem exists, when actual Quality is not equal to desired Quality. (C26) Conception of the domain is of objects, characterised by their attributes and exhibiting an affordance, arising from the potential changes of state of those attributes. (C27)

The HCI/E(U) Conception identifies interactive worksystems, consisting of human and computer behaviours together performing work. (C28) Humans formulate goals and their corresponding behaviors are said to be intentional (or purposeful). Computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive worksystem is a behavioural system distinguished by a boundary, enclosing all human and computer behaviours, whose purpose is to achieve a common goal. (C29) Worksystems achieve goals by the transformation of objects, that is, by producing state changes in the abstract and physical attributes of those objects. (C30) The behaviors of the human and computer are conceptualised as behavioral sub-systems of the worksystem – sub-systems, which interact. (C31) Behavior may be loosely understood as ‘what the user does’ in contrast with ‘what is done’, that is, attribute state changes of the domain. More precisely, the user is conceptualised as a system of distinct, but related, human behaviours identifiable as the sequence of states of a person interacting with a computer to perform work and corresponding with an intentional transformation of objects in a domain. Although possible at many levels, the user must be at least conceptualised at a level commensurate with the level of description of the transformation of objects in the domain. (C32)

In the HCI/E(U) Conception, worksystem behaviours are both physical and abstract. (C33) The latter process information, concerning object-attribute-state changes in the domain, whose transformation is required by goals. Physical behaviours are related to, and express, abstract behaviors. In addition, the user is conceptualised as having cognitive (knowing), conative (trying) and affective (experiencing) aspects. (C34) The user may include both on-line and off-line human behaviours. On-line behaviours are associated with the computer’s representation of the domain; 0ff-line behaviours are associated with non-computer representations of the domain or the latter itself. Conceptualisation of the user as a system of human behaviours is extended to the structures enabling behaviours. (C37) There is a one-to-many mapping between a human’s structures and the behaviours they might enable. The structures may support many different behaviours. Physical human structures are neural, biomechanical and physiological. Mental structures consist of representations and processes, which transform them, (C38)

Work performed by interactive worksystems incurs ‘resource costs’. (C39) Certain costs are associated with the user and distinguished as structural human costs and behavioural human costs. Structural human (‘set-up’ or learning) costs are incurred in the development of human skills and knowledge, as in training and education. Such costs are both mental and physical. (C40) Behavioral human costs are incurred, when the user recruits human structures to perform work. Such costs are both mental and physical. (C41)

In the HCI/E(U) Conception of the HCI Engineering design problem, effectiveness derives from the relationship of an interactive worksystem with its domain. Effectiveness assimilates both the quality of the work performed by the worksystem and the costs incurred by it. (C42) Quality and costs are the primary constituents of the concept of performance through which effectiveness is expressed. A desired performance of an interactive worksystem is conceptualised such that desired performance might be either absolute or relative, as in a comparative performance to be matched or improved upon. (C43) This EU Engineering Conception of performance has the following implications.

First, the quality of the transform, expressing performance, is distinguished from the effectiveness of the worksystem, which produces it. (C44) Second, optimal human behaviours are conceived as those incurring the minimum resource costs in producing a given transform. (C45) Third, common measures of ‘human performance’ – such as ‘time and errors’- are related to performance, as conceived here. (46) Errors may increase resource costs and/or reduce quality. The time taken by human behaviours may (very generally) be associated with increased user costs. Fourth, structural and behavioural human costs may be traded off in performance. (C47) Finally, fifth, user and computer costs may also be traded off. (C48) This concludes a summary of the EU Conception of the HCI Engineering design problem.

The Conception is a unitary view of the necessary concepts and their relations to express that design problem and so, any design solution. In addition, it is a pre-requisite for developing formal HCI Engineering design knowledge as principles to support ‘specify then implement’ HCI engineering design practices. A complete version of the Conception can be found in the short and full versions of the Dowell and Long (1989) original paper – see 2.4 and 2.5.

Footnotes and Citations

Footnotes

 (F1) Other types of design knowledge may also be expressed, using the concepts of the design problem expression, for example, models and methods.

(F2) Implement and test practices also include: trial-and error; prototype and iterate; etc.

Citations

 Dowell and Long (1989)

(C1) ‘…….. a conception of the general design problem …….. is expressed informally as: ‘to design human interactions with computers for effective working’.’  (Page 1513, Lines 12-13)

(C2) ‘A conception is a unitary (and consensus) view of a general design problem; its power lies in the coherence and completeness of its definition of the concepts which can express that problem. Engineering principles are articulated in terms of those concepts. Hence, the requirement for a conception for the HF discipline is concluded (Section 1.5.).’ (Page 1514, Lines 19-22)

(C3) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 39-41)

(C4) ‘…….. one class of general problem is that of the general design problem and includes the design of artefacts (of bridges, for example) and the design of ‘states of the world’ (of public administration, for example).’ (Page 1524, Lines 43-45)

(C5)’…….. any general problem has the necessary property of a scope, delimiting the province of concern of the associated discipline.’ (Page 1514, Lines 47 and 48)

(C6) The scope of the HCI general design problem includes: humans, both as individuals, as groups, and as social organisations; computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines; and work, both with regard to individuals and the organisations in which it occurs. (Page 1515, Lines 11-14)

(C7) ‘…….. The ‘design’ disciplines are ranged according to the ‘hardness’ or ‘softness’ of their respective general design problems. …….. However, here hard and soft problems will be generally distinguished by their determinism for the purpose, that is, by the need for design solutions to be determinate.’ (Page 1517, Lines 31 and 32; and 38-40).

(C8) ‘A discipline’s practices construct solutions to its general design problem……..  disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs. ……..’ (Page 1517, Line 46; Page 1518, Lines 2 and 3).

(C9) ‘Taken together, the dimension of problem hardness, characterising general design problems, and the dimension of specification completeness, characterising discipline practices, constitute a classification space for design disciplines……..’ (Page 1518, Lines 20-22)

(C10) ‘First, a general relation may be apparent between the hardness of a general design problem and the realiseable completeness with which its solutions might be specified. (Page 1518, Lines 20-22)

(C11) ‘Whilst the realiseable completeness with which a discipline may specify design solutions is governed by the hardness of the general design problem, the actual completeness with which it does so is governed by the formality of the knowledge it possesses.’ (Page 1519, Lines 15-18)

(C12)’…….. there exists no pre-ordained relationship between the formality of a discipline’s knowledge and the hardness of its general design problem.’ (Page 1519, Lines 31-33)

(C13) ‘The conception for the (super-ordinate) engineering discipline of HCI asserts a fundamental distinction between behavioural systems which perform work, and a world in which work originates, is performed and has its consequences.’ (Page 1522, Lines 2-4)

(C14) ‘Effectiveness derives from the relationship of an interactive worksystem with its domain of application – it assimilates both the quality of the work performed by the worksystem, and the costs it incurs. ‘(Page 1522, Lines 9-11)

(C15) ‘The concern of an engineering HCI discipline would be the design of interactive worksystems for performance.’ (Page 1522, Lines 13 and 14)

(C16) ‘The interactive worksystem can be distinguished as two separate, but interacting sub-systems, that is, a system of human behaviours interacting with a system of computer behaviours.’ (Page 1523, Lines 1-3)

(C17) ‘The general design problem of HF then, is one of producing implementable specifications of human behaviours {U} which, interacting with computer behaviours {C}, are constituted within a worksystem {S} whose performance conforms with a desired performance (Pd).’ (Page 1523, Lines 11-14)

(C18) ‘The conception for HF identifies a world in which work originates, is performed and has its consequences. This section presents the concepts by which work and its relations with the user are expressed.’ (Page 1523, Lines 19 and 20) (C19) ‘Work occurs in a world consisting of objects and arises in the intersection of organisations and (computer) technology. Objects may be both abstract as well as physical, and are characterised by their attributes.’ (Page 1523, Lines 22-24)

(C20) ‘The different attributes of an object may emerge at different levels within a hierarchy of levels of complexity (see Checkland, 1981).’ (Page 1523, Lines 30 and 31)  

(C21) ‘Attributes of objects are related, and in two ways. First, attributes at different levels of complexity are related. ……..’ (Page 1523, Lines 42 and 43) Second, attributes of objects are related within levels of complexity. …….. (Page 1524, Line 11) (C22) ‘At any point or event in the history of an object, each of its attributes is conceptualised as having a state. Further, those states may change. …….. Objects exhibit an affordance for transformation, engendered by their attributes’ potential for state change (see Gibson, 1977).’ (Page 1524, Lines 15-17 and 19-20)

(C23) ‘A domain of application may be conceptualised as: ‘a class of affordance of a class of objects’.’ (Page 1524, Lines 30 and 31)

(C24) ‘Organisations are conceptualised as having domains as their operational province and of requiring the realisation of the affordance of objects. It is a requirement satisfied through work.’ (Page 1524, Lines 36-38)

(C25) ‘Organisations express their requirement for the transformation of objects through specifying goals. A product goal specifies a required transform – a required realisation of the affordance of an object.’ (Page 1524, Lines 45 and 46; Page 1525, Line 1)

(C26) ‘The transformation of an object demanded by a product goal will generally be of a multiplicity of attribute state changes – both within and across levels of complexity. ……… The concept of quality (Q) describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of work to be equated and evaluated.’ (Page 1525, Lines 23-25 and 29-31)

(C27) ‘Conception of the domain then, is of objects, characterised by their attributes, and exhibiting an affordance arising from the potential changes of state of those attributes.’ (Page 1525, Lines 32-34)

(C28) ‘The conception for HF identifies interactive worksystems consisting of human and computer behaviours together performing work.’ (Page 1526, Lines 2 and 3)

(C29) ‘Humans are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Computers, and machines more generally, are designed to achieve goals, and their corresponding behaviours are said to be intended (or purposive1). An interactive worksystem   (‘worksystem’) is a behavioural system distinguished by a boundary enclosing all human and computer behaviours whose purpose is to achieve and satisfy a common goal.’ (Page 1526, Lines 5-11)

(C30) ‘Worksystems transform objects by producing state changes in the abstract and physical attributes of those objects (see Section 2.2).’ (Page 1526, Lines 17 and 18)

(C31) ‘The behaviours of the human and computer are conceptualised as behavioural sub-systems of the worksystem – sub-systems which interact.’ (Page 1526, Lines 24 and 25)

(C32) ‘Although possible at many levels, the user must at least be expressed at a level commensurate with the level of description of the transformation of objects in the domain.’ (Page 1526, Lines 33-35)

(C33) ‘The behaviours constituting a worksystem are both physical as well as abstract.’ (Page 1526, Lines 39 and 40)

(C34) ‘The user is conceptualised as having cognitive, conative and affective aspects.’ (Page 1527, Line 19)

(C35) ‘Although the human and computer behaviours may be treated as separable sub-systems of the worksystem, those sub-systems extend a “mutual influence”, or interaction whose configuration principally determines the worksystem (Ashby, 1956).’ (Page 1527, Lines 24-27)

(C36) ‘The user may include both on-line and off-line human behaviours: on-line behaviours are associated with the computer’s representation of the domain; offline behaviours are associated with non-computer representations of the domain, or the domain itself.’ (Page 1528, Lines 8-11)

(C37) ‘Conceptualisation of the user as a system of human behaviours needs to be extended to the structures supporting behaviors.’ (Page 1528, Lines 26 and 27)

(C38) ‘Physical human structure is neural, biomechanical and physiological. Mental structure consists of representational schemes and processes.’ (Page 1528, Lines 40 and 41)

(C39) ‘Work performed by interactive worksystems always incurs resource costs.’ (Page 1529, Lines 37 and 38)

(C40) ‘Structural human costs are the costs of the human structures co-extensive with the user.’ (Page 1529, Lines 41 and 42)

(C41) ‘Behavioral human costs are the resource costs incurred by the user (i.e. by human behaviours) in recruiting human structures to perform work. They are both physical and mental resource costs.’ (Page 1530, Lines 12-14)

(C42) ‘The costs of work are conceptualised as the resource costs incurred by the worksystem, and are separately attributed to the human and computer.’ (Page 1531, Lines 1 and 2)

(C43) ‘A desired performance of an interactive worksystem may be conceptualised. Such a desired performance might either be absolute, or relative as in a comparative performance to be matched or improved upon.’ (Page 1531, Lines 8-10)

(C44)…….. the conception of performance is able to distinguish the quality of the transform from the effectiveness of the worksystems which produce them.’ (Page 1531, Lines 17 and 18)

(C45)…….. given the concordance of behaviour with performance, optimal human (and equally, computer) behaviours may be conceived as those which incur a minimum of resource costs in producing a given transform.’ (Page 1531, Lines 22-24)

(C46)……..’the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance.’ (Page 1531, Lines 34 and 35)

(C47) …….. ‘structural and behavioural human costs may be traded-off in performance.’ (Page 1531, Line 39)

(C48)……..’resource costs incurred by the human and the computer may be traded-off in performance.’ (Page 1531, Lines 43 and 44)

(C49)……..’ Instances of the general design problem may include the development of a worksystem, or the utilisation of a worksystem within an organisation. Developing worksystems which are effective, and maintaining the effectiveness of worksystems within a changing organisational environment, are both expressed within the problem.’(Page 1532, Lines 16-20)

2.6 Concepts Carried Forward 150 150 John

2.6 Concepts Carried Forward

2.6.1 Problem

The concept of problem can only be understood in conjunction with the concept of solution. A problem is an unwanted (F1) state-of-affairs (F2) (C1). Once identified (F3), a problem requires a solution (F4). The solution resolves the problem by changing the unwanted state-of affairs to a wanted state-of-affairs. (C2) The concepts of problem and solution are thus closely linked. However, not all problems have a solution (F5); but all solutions have problems. (F6) Problems may have more than one solution (F7) and solutions more than one problem. (F8) (C3) Solutions may be novel or known from their resolution of earlier problems. (F9) (C4)

Footnotes and Citations

Footnotes

 (F1) ‘Desired’ or ‘acceptable’ would be equally good here.

(F2) State-of-affairs, here, includes people, artefacts and the world more generally.

(F3) Problems are not natural phenomena and need to be identified or (better) diagnosed.

(F4) If a problem does not require a solution, then it is not really a problem.

(F5) Hence the concept of the ‘unsolved problem’.

(F6) Even the ‘solution in search of a problem’ is not really a solution till it identifies its problem.

(F7) And equally good solutions at that.

(F8) Also, classes of solution may resolve classes of problem.

(F9) Hence, design knowledge seeks design solutions to design problems.

Citations

 Dowell and Long (1989)

(C1) ‘Any general problem has the necessary property of scope.’ (Page 1514, Lines 47 and 48)

(C2) ‘A discipline’s practices construct solutions to it general design problem.’ (Page 1517, Line 46)

C3) ‘Disciplines appear to differ in the completeness with which they specify solutions to their respective design problems.’ (Page 1518, Lines 3 and 4)

(C4) ‘The features and properties of artefacts or systems that will constitute an optimal solution to a general design problem.’ (Page, 1520, Lines 14 and 15)

2.6.2 Design

The concepts of ‘design’ and ‘implementation’ are closely linked to each other. (F1) In general, designs are for implementation and implementations are of designs. (F2) (C1) (C7) A design represents (F3) an object or artefact. (C6) An implementation realises (F4) the object or artefact. (F5) (C2) However, designs may remain unimplemented and implementations may not have been designed. (F6) (C3) (C4) (C5)

Footnotes and Citations

Footnotes

(F1) In fact, their contrast is an essential feature of both their meanings.

(F2) However, design and implementation also exist independently of each other (see also (6)).

(F3) The representation may take many forms: sketch; text; drawing; diagram; model; instructions etc.

(F4) ‘Realises’ here could as well be replaced by: ‘constructs’; ‘makes’; ‘renders’ etc.

(F5) Design can also be used of people, as in education or training.

(F6) An unimplemented design remains a design. An undesigned implementation is not, however, strictly speaking an implementation; but simply an object or artefact.

Citations

 Dowell and Long (1989)

(C1) ‘… one class of general problem is that of the general design problem and includes the design of artefact (of bridges, for example) and the design of ‘states of the world’ (public administration, for example).’ (Page 1514, Lines 43-45)

(C2) ‘Thus, HCI is a discipline addressing a general design problem expressed informally as: ‘to design human-computer interactions for effective working.’ (Page 1515, Lines 9 and 10)

(C3) ‘The design disciplines are ranged according to the ‘hardness’ or ‘softness’ of their respective general design problem.’ (Page 1517, Lines 31 and 32)

(C4) ‘… disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs.’ (Page 1518, Lines 1 and 2)

(C5) ‘Taken together, the dimension of problem hardness, characterising general design problems and the dimension of specification completeness,  characterising discipline practices, constitute a classification space for design disciplines.’ (Page 1518, Lines 15-17)

(C6) ‘the concern of an Engineering HCI discipline would be the design of interactive worksystems for performance.’ (Page 1522, Lines 13 and 14)

(C7) ‘Instances of the general design problem may include the development of a worksystem, or the utilisation of a worksystem within an organisation.’ (Page 1532, Lines 16-18)

2.6.3 Design Problem

The concept of ‘design problem’ is a conjunction of ‘design’ and ‘problem’. (C1) However, the order makes clear, that design qualifies problem and not the reverse. (F1) (C2) Here, the concept of design problem is defined by intersecting the concept of design (2.6.1) with the concept of problem (2.6.2), a definition in which the latter is qualified by the former. (C3) A design problem is a state-of-design affairs (F2), which is not as wanted. (F3) Once identified, a design problem requires a design solution, which represents the designed state-of-affairs and which, if implemented, realises that state-of-affairs. (F4) (C4) (C5) However, not all design problems have design solutions and not all design solutions are implemented. (C6) But all design solutions imply design problems. (F5) Design problems may have more than one design solution and design solutions more than one problem. (C7) The latter may have more than one implementation. (C8) Design solutions may be novel or known from their resolution of earlier design problems. (F6) (C9)

Footnotes and Citations

Footnotes

 (F1) Design problems, then, are a subset of problems. Problems designs, in contrast, are a subset of designs.

(F2) Design state-of-affairs concern objects; artefacts; people; and the world, more generally.

(F3) More specifically, the people, objects, or states-of-affairs expressed by the design problem, are not as wanted.

(F4) The concepts of design problem and design solution are, thus, closely linked.

(F5) If no design problem is implied, then the so-called design solution is only a design and not a solution.

(F6) Such knowledge constitutes design knowledge.

Citations

 Dowell and Long (1989)

(C1) ‘…….. a conception of the general design problem …….. is expressed informally as: ‘to design human interactions with computers for effective working’.’  (Page 1513, Lines 12-13)

(C2) ‘A conception is a unitary (and consensus) view of a general design problem.’ (Page 1514, Lines 19)

(C3) ‘Most definitions of disciplines assume three primary characteristics: a general problem; practices, providing solutions to that problem; and knowledge, supporting those practices.’ (Page 1514, Lines 39-41)

(C4) ‘…….. one class of general problem is that of the general design problem and includes the design of artefacts (of bridges, for example) and the design of ‘states of the world’ (of public administration, for example).’ (Page 1524, Lines 43-45)

(C5) The scope of the HCI general design problem includes: humans, both as individuals, as groups, and as social organisations; computers, both as programmable machines, stand-alone and networked, and as functionally embedded devices within machines; and work, both with regard to individuals and the organisations in which it occurs. (Page 1515, Lines 11-14)

(C6) ‘…….. The ‘design’ disciplines are ranged according to the ‘hardness’ or ‘softness’ of their respective general design problems. …….. (Page 1517, Lines 31 and 32)

(C7) ‘A discipline’s practices construct solutions to its general design problem……..  disciplines appear to differ in the completeness with which they specify solutions to their respective general design problems before implementation occurs. ……..’ (Page 1517, Line 46; Page 1518, Lines 2 and 3).

(C8) ‘Taken together, the dimension of problem hardness, characterising general design problems, and the dimension of specification completeness, characterising discipline practices, constitute a classification space for design disciplines……..’ (Page 1518, Lines 20-22)

(C9) ‘The general design problem of HF then, is one of producing implementable specifications of human behaviours {U} which, interacting with computer behaviours {C}, are constituted within a worksystem {S} whose performance conforms with a desired performance (Pd).’ (Page 1523, Lines 11-14)