The initial framework for a craft approach to HCI follows. The key concepts appear in bold.

The framework for a discipline of HCI as craft has a general problem with a particular scope. Research acquires and validates knowledge, which supports practices, solving the general problem.

Key concepts are defined below (with additional clarification in brackets).

Framework: a basic supporting structure (basic – fundamental; supporting – facilitating/making possible; structure – organisation).

Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI: human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Craft: best practice design (practice – design/evaluation; design – specification/implementation.

General Problem: craft design (craft – best practice; design – specification/implementation).

Particular Scope: human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Research: acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Knowledge: supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Practices: supported by knowledge (supported – facilitated; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Solution: resolution of a problem (resolution – answer/address; problem – question/doubt).

General Problem: craft design (craft – best practice; design – specification/implementation).

The final framework for an craft approach to HCI follows. It comprises the initial framework (see earlier) and, in addition, key concept definitions (but not clarifications).

This framework for a discipline of HCI as craft is more complete, coherent and fit-for-purpose than the description afforded by the craft approach to HCI (see earlier). The framework thus better supports thinking about and doing craft HCI. As the framework is explicit, it can be shared by all interested researchers. Once shared, it enables researchers to build on each other’s work. This sharing and building is further supported by a re-expression of the framework, as a design research exemplar. The latter specifies the complete design research cycle, which once implemented constitutes a case-study of an of a craft approach to HCI. The diagram, which follows, presents the craft design research exemplar. The empty boxes are not required for the design research exemplar of HCI as Innovation; but are required elsewhere for the design research exemplar of HCI as Engineering. They have been included here for completeness.

Examples of such levels are presented here – first a short version and then a long version. Researchers, of course, might have their own lower level descriptions or subscribe to some more generally recognised levels. Such descriptions are acceptable, as long as they fit with the higher level descriptions of the framework and are complete; coherent and fit-for-purpose. In the absence of alternative levels of description, researchers might try the short version first .

These levels go, for example from ‘human’ to ‘user’ and from ‘computer’ to ‘interactive system’. The lowest level, of course, needs to reference the application, in terms of the application itself and the interactive system. Researchers are encouraged to select from the framework extensions as required and to add the lowest level description, relevant to their research. The lowest level is used here to illustrate the extended craft framework.

Following the Craft Design Research exemplar diagram, researchers need to specify:  User Requirements (unsatisfied); Craft Research; Craft Knowledge; and Interactive System (satisfying User Requirements).

These specifications require the extended Craft framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Craft design requires the Interactive System to do something (the Application) as desired (Performance). Craft Research acquires and validates Craft Knowledge to support Craft Design Practices.

The Craft Framework Extension, thus includes: Application; Interactive System; and Performance.

1. Craft Applications

1.1 Objects

Craft applications (the ‘ something’, which the interactive system does) can be described in terms of objects. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, a website application (such as for an academic organisation) can be described for design research purposes in terms of objects; their abstract attributes, supporting the creation of websites; their physical attributes supporting the visual/verbal representation of displayed information on the website pages by means of text and images. Application objects are specified as part of craft design and can be researched as such.

1.2 Attributes and Levels

The attributes of a craft application object emerge at different levels of description. For example, characters and their configuration on a webpage are physical attributes of the object ‘webpage’, which emerge at one level. The message on the page is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of a craft application object are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description. Such relations are specified as part of craft design.

1.4 Attribute States and Affordance

The attributes of craft application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a website page (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

A craft application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The object ‘website’ may be associated within the application as that of site structure (state changes of its organisational attributes) and the  authorship (state changes of its textual and image content). In principle, an application may have any level of generality, for example, the writing of personal pages and the writing of academic pages.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing for a special group of users’, may each have a website page as their transform, where the pages are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those pages would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute an additional (unsatisfied) User Requirement and result in a new Interactive System.

1.6 Application Goals

The requirement for the transformation of craft application objects is expressed in the form of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a website page, making its messages less complex and so more clear, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text  and images and of associated syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter might constitute part of a craft design.

1.7 Craft Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – website pages with different styles. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal.

1.8 Craft Application and the User

One description of the application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, users express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’.

From product goals is derived a structure of related task goals, which can be assigned, by craft design practice, either to the user or to the interactive computer (or both) within an associated interactive system. Task goals assigned to the user by craft design are those, intended to motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Craft Interactive Computers

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a webmaster, using a website application, whose purpose is to construct websites, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The webmaster and the website application may transform the object ‘page’ by changing both the attributes of its meaning and the attributes of its layout, both text and images.

The behaviours of the human and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the human does’, in contrast with ‘what is done’ (i.e. attribute state changes of application objects).

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a webmaster interacting with a website application is a user, whose behaviours include receiving and replying to messages, sent to the website.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours. They are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine, and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a webmaster has the product goal, required to maintain the circulation of a website newsletter to a target audience. The webmaster interacts with the computer by means of the user interface (whose behaviours include the transmission of information in the newsletter). Hence, the webmaster acquires a representation of the current circulation by collating the information displayed by the computer screen and assessing it by comparison with the conditions, specified by the product goal. The webmaster reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour – selecting menu options, for example.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems extert a ‘mutual influence’ or interaction. Their configuration principally determines the interactive system and craft design and research.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a webmaster interact with the behaviours of a website application. The webmaster’s behaviours influence the behaviours of the interactive computer (access the image function), while the behaviours of the interactive computer influence the selection behaviour of the webmaster (among possible image types). The design of their interaction – the webmaster’s selection of the image function, the computer’s presentation of possible image types – determines the interactive system, comprising the webmaster and interactive computer behaviours in their planning and control of webpage creation. The interaction may be the object of craft design and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of an inappropriate image, required on a page is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the field for the appropriate image as an attribute state change in the spacing of the page. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early image editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the GUI ‘fill-in’ behaviours. Craft design research would be expected to have contributed to the latter . The assignment of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated with the user and distinguished as behavioural user costs.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of behaviours) to effect an application. They are both physical and mental. Physical costs are those of physical behaviours, for example, the costs of using the mouse and of attending to a  screen display; they may be expressed for craft design purposes as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed for craft design purposes as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs.

3. Performance of the Craft Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is, performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued. Desired performance is the object of craft design.

Behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of craft design and so of design research.

The common measures of human ‘performance’ – errors and time, are related in this notion of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Following the Craft Design Research exemplar diagram, researchers need to specify: User Requirements (unsatisfied); Craft Research; Craft Knowledge; and Interactive System (satisfying User Requirements).

These specifications require the extended Craft framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Craft design requires the Interactive System to do something (the Application) as desired (Performance). Craft Research acquires and validates Craft Knowledge to support Craft Design Practice.

The Craft Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Craft Applications

1.1 Objects

Craft applications (the ‘something’ the interactive system ‘does’) can be described as objects. Such applications occur in the need of organisations for interactive systems. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, a website application (such as for an academic organisation) can be described, for design research purposes, in terms of objects; their abstract attributes, supporting the communication of messages; their physical attributes supporting the visual/verbal representation of displayed information by means of language.

1.2 Attributes and Levels

The attributes of a craft application object emerge at different levels of description. For example, characters and their configuration on a webpage are physical attributes of the object ‘webpage’, which emerge at one level. The message on he page is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of craft application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description.

1.4 Attribute States and Affordance

The attributes of craft application objects can bedescribed as having states. Further, those states may change. For example, the content and characters (attributes) of a website page (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

A craft application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The object ‘website’ may be associated within the application as that of site structure (state changes of its organisational attributes) and the authorship (state changes of its textual and image content). In principle, an application may have any level of generality, for example, the writing of personal pages and the writing of academic pages.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing for a special group of users’, may each have a website page as their transform, where the pages are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those pages would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute an additional (unsatisfied) User Requirement and result in a new Interactive System.

1.6 Application Goals

Organisations express the requirement for the transformation of craft application objects in terms of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal generally supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a website page, making its messages less complex and so more clear, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and images and of associated syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter might constitute part of a craft design.

1.7 Craft Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy the same product goal – website pages with different styles, for example, where different transforms exhibit different compromises between attribute state changes of the application object. There may also be transforms, which fail to meet the product goal. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of an application to be equated and evaluated. Such transforms may become the object of craft design and so research.

1.8 Craft Application and the User

Description of the craft application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, organisations express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’, which occurs only by means of objects, affording transformation and interactive systems, capable of producing a transformation. Novel production may be (part of) a craft design.

From product goals is derived a structure of related task goals, which can be assigned either to the user or to the interactive computer (or both) within the design of an associated interactive system. The task goals assigned to the user are those, which motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Craft Interactive Computers and the Human

2.1 Interactive Systems

Users are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Interactive computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive).

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a webmaster, using a website application, whose purpose is to construct websites, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The webmaster and the website application may transform the object ‘page’ by changing both the attributes of its meaning and the attributes of its layout, both text and images. More generally, an interactive system may transform an object through state changes, produced in related attributes.

The behaviours of the user and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the user does’, in contrast with ‘what is done’ (that is, attribute state changes of application objects). More precisely the user is described as:

a system of distinct and related user behaviours, identifiable as the sequence of states of a user interacting with a computer to do something as desired and corresponding with a purposeful (intentional) transformation of application objects.

Although expressible at many levels of description, the user must at least be described for design research purposes at a level, commensurate with the level of description of the transformation of craft application objects. For example, a webmaster interacting with a website application is a user, whose behaviours include receiving and replying to messages, sent to the website.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours, which extend a mutual influence – they are related. In particular, they are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a webmaster has the product goal, required to maintain the circulation of a website newsletter to a target audience. The webmaster interacts with the computer by means of the user interface (whose behaviours include the transmission of information in the newsletter). Hence, the webmaster acquires a representation of the current circulation by collating the information displayed by the computer screen and assessing it by comparison with the conditions, specified by the product goal. The webmaster reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour – selecting menu options, for example.

The user is described as having cognitive, conative and affective aspects. The cognitive aspects are those of knowing, reasoning and remembering; the conative aspects are those of acting, trying and persevering; and the affective aspects are those of being patient, caring and assuring. Both mental and overt user behaviours are described as having these three aspects, all of which may contribute to ‘doing something, as desired wanted/needed/experienced/felt/valued.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems exert a ‘mutual influence’, that is to say they interact. Their configuration principally determines the interactive system and so its design and the associated research into that and other possible designs.

Interaction of the user and the interactive computer behaviours is the fundamental determinant of the interactive system, rather than their individual behaviours per se. Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a webmaster interact with the behaviours of a website application. The webmaster’s behaviours influence the behaviours of the interactive computer (access the image function), while the behaviours of the interactive computer influence the selection behaviour of the webmaster (among possible image types). The design of their interaction – the webmaster’s selection of the image function, the computer’s presentation of possible image types – determines the interactive system, comprising the webmaster and interactive computer behaviours in their planning and control of webpage creation. The interaction may be the object of craft design and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of an inappropriate image, required on a page is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the field for the appropriate image as an attribute state change in the spacing of the page. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early image editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the GUI ‘fill-in’ behaviours. Craft design research would be expected to have contributed to the latter . The assignment of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human On-line and Off-line Behaviours

User behaviours may comprise both on-line and off-line behaviours: on-line behaviours are associated with the interactive computer’s representation of the application; off-line behaviours are associated with non-computer representations of the application.

As an illustration of the distinction, consider the example of an interactive system, consisting of the behaviours of a web secretary and an interactive application. They are required to produce a paper-based copy of a dictated letter, stored on audio tape. The product goal of the interactive system here requires the transformation of the physical representation of the letter from one medium to another, that is, from tape to paper. From the product goal derives the task goals, relating to required attribute state changes of the letter. Certain of those task goals will be assigned to the secretary. The secretary’s off-line behaviours include listening to and assimilating the dictated letter, so acquiring a representation of the application object. By contrast, the secretary’s on-line behaviours include specifying the represention by the interactive computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols.

On-line and off-line user behaviours are a particular case of the ‘internal’ interactions between a user’s behaviours as, for example, when the secretary’s keying interacts with memorisations of successive segments of the dictated letter.

2.5 Structures and the Human

Description of the user as a system of behaviours needs to be extended, for the purposes of design and design research, to the structures supporting that behaviour.

Whereas user behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘the support for the human to be able to do what they do’. There is a one-to-many mapping between a user’s structures and the behaviours they might support: thus, the same structures may support many different behaviours.

In co-extensively enabling behaviours at each level of description, structures must exist at commensurate levels. The user structural architecture is both physical and mental, providing the capability for a user’s overt and mental behaviours. It provides a represention of application information as symbols (physical and abstract) and concepts, and the processes available for the transformation of those representations. It provides an abstract structure for expressing information as mental behaviour. It provides a physical structure for expressing information as physical behaviour.

Physical user structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, user structure has cognitive, conative and affective aspects. The cognitive aspects of user structures include information and knowledge – that is, symbolic and conceptual representations – of the application, of the interactive computer and of the user themselves, and it includes the ability to reason. The conative aspects of user structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of user structures include the personality and temperament, which respond to and support behaviour. All three aspects may contribute to ‘ doing something, as desired wanted/needed/experienced/felt/valued’.

To illustrate this description of mental structure, consider the example of the structures supporting a web user’s behaviours. Physical structure supports perception of the  web page display and executing actions to the web application. Mental structures support the acquisition, memorisation and transformation of information about the pages are annotated, for example. The knowledge, which the user has of the web application and of the interactive computer, supports the collation, assessment and reasoning about the actions required.

The limits of user structures determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the application and the interactive computer; memory and attentional capacities; patience; perseverence; dexterity; and visual acuity etc. The structural limits on behaviour may become particularly apparent, when one part of the structure (a channel capacity, perhaps) is required to support concurrent behaviours, perhaps simultaneous visual attending and reasoning behaviours. The user then, is ‘resource-limited’ by the co-extensive user structures.

The behavioural limits of the user, determined by structure, are not only difficult to define with any kind of completeness, they may also be variable, because that structure may change, and in a number of ways. A user may have self-determined changes in response to the application – as expressed in learning phenomena, acquiring new knowledge of the application, of the interactive computer, and indeed of themselves, to better support behaviour. Also, user structures degrade with the expenditure of resources by behaviour, as demonstrated by the phenomena of mental and physical fatigue. User structures may also change in response to motivating or de-motivating influences of the organisation, which maintains the interactive system.

It must be emphasised that the structure supporting the user is independent of the structure supporting the interactive computer behaviours. Neither structure can make any incursion into the other and neither can directly support the behaviours of the other. (Indeed this separability of structures is a pre-condition for expressing the interactive system as two interacting behavioural sub-systems). Although the structures may change in response to each other, they are not, unlike the behaviours they support, interactive; they are not included within the interactive system. The combination of structures of both user and interactive computer, supporting their interacting behaviours is described as the user interface .

2.6 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated directly with the user and distinguished as structural user costs and behavioural user costs.

Structural user costs are the costs of the user structures. Such costs are incurred in developing and maintaining user skills and knowledge. More specifically, structural user costs are incurred in training and educating users, so developing in them the structures, which will enable the behaviours necessary for an application . Training and educating may augment or modify existing structures, provide the user with entirely novel structures, or perhaps even reduce existing structures. Structural user costs will be incurred in each case and will frequently be borne by the organisation. An example of structural user costs might be the costs of training a secretary to use a web-based GUI interface in the particular style of layout, required for an organisation’s correspondence with its clients and in the operation of the interactive computer by which that layout style can be created.

Structural user costs may be differentiated as cognitive, conative and affective structural costs. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of users and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for ‘doing something as desired’. Conative structural costs express the costs of developing the activity, stamina and persistence of users as necessary for an application. Affective structural costs express the costs of developing in users their patience, care and assurance as necessary for an application.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of their of behaviours) in recruiting user structures to effect an application. They are both physical and mental resource costs. Physical behavioural costs are the costs of physical behaviours, for example, the costs of making keystrokes on a keyboard and of attending to a  screen display; they may be expressed without differentiation as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed without differentiation as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs. Costs are an important aspect of the design of an interactive computer system.

When differentiated, mental and physical behavioural costs are described as the cognitive, conative and affective behavioural costs of the user. Cognitive behavioural costs relate to both the mental representing and processing of information and the demands made on the user’s extant knowledge, as well as the physical expression thereof in the formulation and expression of a novel plan. Conative behavioural costs relate to the repeated mental and physical actions and effort, required by the formulation and expression of the novel plan. Affective behavioural costs relate to the emotional aspects of the mental and physical behaviours, required in the formulation and expression of the novel plan. Behavioural user costs are evidenced in user fatigue, stress and frustration; they are costs borne directly by the user and so need to be taken into account in the design process.

3. Performance of the Craft Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued.

A concordance is assumed between the behaviours of an interactive system and its performance: behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer. Specifically, the resource costs incurred by the user are differentiated as: structural user costs – the costs of establishing and maintaining the structures supporting behaviour; and behavioural user costs – the costs of the behaviour, recruiting structure to its own support. Structural and behavioural user costs are further differentiated as cognitive, conative and affective costs. Design requires attention to all types of resource costs – both those of the user and of the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of craft design and so of design research.

Discriminating the user’s performance within the performance of the interactive system would require the separate assimilation of user resource costs and their achievement of desired attribute state changes, demanded by their assigned task goals. Further assertions concerning the user arise from the description of interactive system performance. First, the description of performance is able to distinguish the goodness of the transforms from the resource costs of the interactive system, which produce them. This distinction is essential for design, as two interactive systems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, it would be the lesser (in terms of performance) of the two systems.

Second, given the concordance of behaviour with ‘doing something as desired’, optimal user (and equally, interactive computer) behaviours may be described as those, which incur a (desired) minimum of resource costs in producing a given transform. Design of optimal user behaviour would minimise the resource costs, incurred in producing a transform of a given goodness. However, that optimality may only be categorically determined with regard to interactive system performance and the best performance of an interactive system may still be at variance with what is desired of it. To be more specific, it is not sufficient for user behaviours simply to be error-free. Although the elimination of errorful user behaviours may contribute to the best application possible of a given interactive system, that performance may still be less than ‘as desired’. Conversely, although user behaviours may be errorful, an interactive system may still support ‘doing something, as desired’.

Third, the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Fourth, structural and behavioural user costs may be traded-off in the design of an application. More sophisticated user structures, supporting user behaviours, that is, the knowledge and skills of experienced and trained users, will incur high (structural) costs to develop, but enable more efficient behaviours – and therein, reduced behavioural costs.

Fifth, resource costs, incurred by the user and the interactive computer may be traded-off in the design of the performance of an application. A user can sustain a level of performance of the interactive system by optimising behaviours to compensate for the poorly designed behaviours of the interactive computer (and vice versa), that is, behavioural costs of the user and interactive computer are traded-off in the design process. This is of particular importance as the ability of users to adapt their behaviours to compensate for the poor design of interactive computer-based systems often obscures the fact that the systems are poorly designed.

Requirement 1: The framework (as a basic support structure) is for a discipline (as an academic field of study and branch of knowledge).

Goldsteijn et al. are clearly concerned with design, both the design of their tool ‘Materialise’ and the crafting designs of the users thereof. However, there is no explicit mention of a superordinate discipline or field of study/branch of knowledge, for example, such as science (as it relates to understanding or engineering, as it relates to design). The design is of human-computer crafting interactions. See Comments 1, 2, 5, 8 and 9.

Requirement 2: The framework is for HCI  (as human-computer interaction) as craft (as best practice).

The paper espouses HCI in the form of human-computer crafting interactions. Further, the development of the tool ‘Materialise’ to support crafting is supported by best practice, both in terms of Goldsteijn et al’s own experience and the application of generic HCI knowledge, for example, the iterative design method used in the tool development (Comments 10 and 13). Even the guidelines proposed can be thought of as their recommended best practice.

Requirement 3: The framework has a general problem (as craft design) with a particular scope (as craft human-computer interactions to do something as desired).

The paper espouses the general problem of craft design in the form of the development of the crafting tool ‘Materialise’. Its particular scope is crafting human-computer interactions to do something as desired (or some-such – see Comment4). Various qualities are associated with crafting as wanted, for example, creativity etc.

Requirement 4: Research ( as acquisition and validation) acquires (as study and practice) and validates (as confirms) knowledge (heuristics/methods/expert advice/successful designs/case-studies).

Goldsteijn et al. are clearly reporting design research and have explicitly formulated questions on the subject (Comment 9). The tool ‘Materialise’ also clearly constitutes HCI design knowledge (case-studies), as does their own enhanced experience and the expert advice, which they offer, in the form of guidelines/heuristics/expert advice (Comments 6 and 9). The tool and the guidelines are explicit, the experience implicit. Although all are ‘acquired’, none has been validated (Comment 14).

Requirement 5: The framework embodies knowledge, which supports (facilitates) practices (as trial and error and implement and test), which solve (as resolve) the general design problem of craft design.

Goldsteijn et al’s tool and guidelines appear intended to support design practices of trial and error and implement and test, much in the manner of the development of the tool itself Comment 10). Such practices, however, are not the object of this particular research and so their successful resolution of the craft design problem remains undemonstrated (Comment 14).

Conclusion: Goldsteijn et al’s paper denies that it is proposing a framework for HCI design or analysis. This is accepted. However, it has many of the required elements of a framework and so could constitute the basis for the development of one. For example, it is clearly committed to design; it contains a detailed  conception of crafting and associated lower-level descriptions in different domains; it employs an (albeit generic) HCI design method; it produces an HCI design tool; and it considers implicit User Requirements (Comments Comments 1, 2, 3, 5, 6, 7, 10, 12 and 14).

Goldsteijn et al’s paper can be considered the basis for the development of a  framework of HCI craft design. Such development would need to include further details concerning: the discipline/field of study of design; its level of description (needs to be higher and to link with the lower-lower descriptions referenced); whether its components are implicit or explicit; and what constitutes its idea of validation, including – conceptualisation; operationalisation; test; and generalisation.

The frameworks proposed here might be useful in any such development.

Discipline

Innovation – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Art – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Craft – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Applied – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Science – Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Engineering – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI

Innovation – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Art – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Craft – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Applied – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Science – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Engineering – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Framework Type

Innovation – Innovation: novel (novel – new ideas/methods/devices etc)

Art – Art: creative expression corresponding to some ideal or criteria (creative – imaginative, inventive); (expressive – showing by taking some form); ideal – visionary/perfect); criterion – standard).

Craft – Craft: best practice design (practice – design/evaluation; design – specification/implementation).

Applied – Applied: application of other discipline knowledge (application – addition to/prescription; discipline – academic field/branch of knowledge; knowledge – information/learning).

Science – understanding (explanation/prediction)

Engineering – design for performance (design – specification/implementation; performance – how well effected).

General Problem

Innovation – innovation design (innovation – novelty; design – specification/implementation).

Art – art design (art – ideal creative expression; design – specification/implementation).

Craft – craft design (craft – best practice; design – specification/implementation).

Applied – applied design (applied – added/prescribed; design – specification/implementation).

Science – understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

Engineering – engineering design (engineering – design for performance; design – specification/implementation).

Particular Scope

Innovation – innovative human-computer interactions to do something as desired (innovative – novel; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued).

Art – art human-computer interactions to do something as desired (art – creation/expression; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task); desired: wanted/needed/experienced/felt/valued).

Craft – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Applied – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Science – human-computer interactions to do something as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued.

Engineering – human-computer interactions to perform tasks effectively as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; perform – effect/carry out; tasks – actions; desired – wanted/needed/experienced/felt/valued).

Research

Innovation – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – patents/expert advice/experience/examples).

Art – acquires and validates knowledge (acquires – creates by study/practice; validates – confirms; knowledge – experience/expert advice/other artefacts.

Craft – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Science – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools; practices – explanation/prediction).

Engineering – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Knowledge

Innovation – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Art – supports practices (supports – facilitates/makes possible; practices – trial and error/implement and test).

Craft – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Applied – supports practices (supports – facilitates/makes possible; practices – trial-and-error/apply and test).

Science – supports practices (supports – facilitates/makes possible; practices – explanation/prediction).

Engineering – supports practices (supports – facilitates/makes possible; practices – diagnose design problems/prescribe design solutions).

Practices

Innovation – supported by knowledge (supported – facilitated; knowledge – patents/expert advice/experience/examples).

Art – supported by knowledge (supported – facilitated/made possible; knowledge – experience/expert advice/other artefacts).

Craft – supported by knowledge (supported – facilitated; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – supported by knowledge (supported – facilitated; knowledge – guidelines; heuristics/methods/expert advice/successful designs/case-studies).

Science – supported by knowledge (supported – facilitated; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools ).

Engineering – supported by knowledge (supported – facilitated; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Solution

Innovation – resolution of a problem (resolution – answer/address; problem – question/doubt).

Art – resolution of the general problem (resolution – answer/address; problem – question/doubt).

Craft – resolution of a problem (resolution – answer/address; problem – question/doubt).

Applied – resolution of a problem (resolution – answer/address; problem – question/doubt).

Science – resolution of a problem (resolution – answer/address; problem – question/doubt).

Engineering – resolution of a problem (resolution – answer/address; problem – question/doubt).

The initial framework for an applied approach to HCI follows. The key concepts appear in bold.

The framework for a discipline of HCI as applied has a general problem with a particular scope. Research acquires and validates knowledge, which supports practices, solving the general problem.

Key concepts are defined below (with additional clarification in brackets).

Framework: a basic supporting structure (basic – fundamental; supporting – facilitating/making possible; structure – organisation).

Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI: human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Applied: application of other discipline knowledge (application – addition to/prescription; discipline – academic field/branch of knowledge; knowledge – information/learning.

General Problem: applied design (applied – added/prescribed; design – specification/implementation).

Particular Scope: human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Research: acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Knowledge: supports practices (supports – facilitates/makes possible; practices – trial-and-error/apply and test).

Practices: supported by knowledge (supported – facilitated; knowledge – guidelines; heuristics/methods/expert advice/successful designs/case-studies).

Solution: resolution of a problem (resolution – answer/address; problem – question/doubt).

General Problem: applied design (applied – added/prescribed; design – specification/implementation).

This framework for a discipline of HCI as applied is more complete, coherent and fit-for-purpose than the description afforded by the applied approach to HCI (see earlier). The framework thus better supports thinking about and doing applied HCI. As the framework is explicit, it can be shared by all interested researchers. Once shared, it enables researchers to build on each other’s work. This sharing and building is further supported by a re-expression of the framework, as a design research exemplar. The latter specifies the complete design research cycle, which once implemented constitutes a case-study of an of an applied approach to HCI. The diagram, which follows, presents the applied design research exemplar. The empty boxes are not required for the design research exemplar of HCI as Applied; but are required elsewhere for the design research exemplar of HCI as Engineering. They have been included here for completeness.

Examples of such levels are presented here – first a short version and then a long version. Researchers, of course, might have their own lower level descriptions or subscribe to some more generally recognised levels. Such descriptions are acceptable, as long as they fit with the higher level descriptions of the framework and are complete; coherent and fit-for-purpose. In the absence of alternative levels of description, researchers might try the short version first .

These levels go, for example from ‘human’ to ‘user’ and from ‘computer’ to ‘interactive system’. The lowest level, of course, needs to reference the applied design itself, in terms of the application, for example, for a business interactive system, secretary and electronic mailing facility. Researchers are encouraged to select from the framework extensions as required and to add the lowest level description, relevant to their research. The lowest level is used here to illustrate the extended applied framework.

Following the Applied Design Research exemplar diagram above, researchers need to specify: Specific Applied Problems (as they relate to User Requirements); Applied Research; Applied Knowledge; and Specific Applied Solutions (as thy relate to Interactive Systems).

These specifications require the extended Applied framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Applied design requires the Interactive System to do something (the Application) as desired (Performance). Applied Research acquires and validates Applied Knowledge to support Applied Design Practices.

The Applied Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Applied Applications

1.1 Objects

Applied applications (the ‘ something’, which the interactive system does) can be described in terms of objects. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, an applied GUI e-mail application, favouring the recognition of text and images over the recall of commands (such as for correspondence), can be described for design research purposes in terms of objects; their abstract attributes, supporting the communication of messages; their physical attributes supporting the GUI visual/verbal representation of displayed information by means of language. Applied objects are specified as part of design and can be researched as such.

1.2 Attributes and Levels

The attributes of an applied application object emerge at different levels of description. For example, characters and their configuration on a GUI page are physical attributes of the object ‘e-mail,’ which emerge at one level. The message of the e-mail is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of applied application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description. Such relations are specified as part of Applied design.

1.4 Attribute States and Affordance

The attributes of applied application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of an applied GUI e-mail (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

An applied application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The GUI object ‘book’ may be associated with the application of typesetting (state changes of its layout attributes) and with the application of authorship (state changes of its textual content). In principle, an application may have any level of generality, for example, the writing of GUI personal e-mails and the writing of business e-mails. Object/attribute expression, as in the case of GUI e-mails, favours the recognition over the recall of command instructions.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing to a friend’, each have a GUI e-mail as their transform, where the e-mails are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those e-mails would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute a Specific Applied Problem and lead to a new design, which embodies a Specific Applied Solution.

1.6 Application Goals

The requirement for the transformation of applied application objects is expressed in the form of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a GUI e-mail, making its message more courteous, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and of syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter, favouring recognition over recall of command instructions, might constitute part of an applied design.

1.7 Applied Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – GUI e-mails with different styles. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal.

1.8 Applied Application and the User

One description of the applied application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, users express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’.

From product goals is derived a structure of related task goals, which can be assigned, by design practice, either to the user or to the interactive computer (or both) within an associated interactive system. Task goals assigned to the user by the design are those, intended to motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Applied Interactive Computers

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a secretary and GUI electronic e-mail application, whose purpose is to conduct correspondence, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The secretary and GUI e-mail application may transform the object ‘correspondence’ by changing both the attributes of its meaning and the attributes of its layout by means of recognised, as opposed to recalled command instructions.

The behaviours of the human and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the human does’, in contrast with ‘what is done’ (i.e. attribute state changes of application objects).

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a secretary interacting with an GUI electronic mail application is a user, whose behaviours include receiving and replying to messages by means of recognised, rather than recalled command instructions.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours. They are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine, and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a travel company secretary has the product goal, required to maintain the circulation of an electronic newsletter to customers. The secretary interacts with the computer by means of the applied GUI interface (whose behaviours include the icon-based transmission of information about the newsletter). Hence, the secretary acquires a representation of the current circulation by collating the information displayed by the GUI screen and assessing it by comparison with the conditions, specified by the product goal. The secretary reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour, that is, recognising icons, rather than recalling and keying text-based commands – selecting  GUI menu options.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems extert a ‘mutual influence’ or interaction. Their configuration principally determines the interactive system and applied design and research.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a secretary interact with the behaviours of a GUI e-mail application. The secretary’s behaviours influence the behaviours of the interactive computer (access the dictionary function), while the behaviours of the interactive computer influence the selection behaviour of the operator (among possible correct spellings). The design of their interaction – the secretary’s selection of the dictionary function, the computer’s presentation of possible spelling corrections – determines the interactive system, comprising the secretary and interactive computer behaviours in their planning and control of correspondence. The interaction may be the object of applied design, favouring recognition over recall and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of a mis-spelled word, required in a document is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the text field for the correctly spelled word demands an attribute state change in the text spacing of the document. Specifying that state change may be a task goal assigned to the user by recalled command instructions, as in interaction with the behaviours of early text editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the applied easily recognised GUI ‘wrap-round’ behaviours. Design research would be expected to have been involved in such innovations. The assignment of the expression of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated with the user and distinguished as behavioural user costs.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of behaviours) to effect an application. They are both physical and mental. Physical costs are those of physical behaviours, for example, the costs of keying or of attending the GUI menu options; they may be expressed for applied design purposes as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed for  design purposes as mental workload. Recognition behavioural costs, for example, have been shown to be lower that those of recall behaviours. Hence, the popularity of GUI interfaces. Mental behavioural costs are ultimately manifest as physical behavioural costs, for example, menu option selection or text input keying.

3. Performance of the Applied Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued. Desired performance is the object of innovation design.

Behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of design and so of design research.

The common measures of human ‘performance’ – errors and time, are related in this notion of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Following theApplied Design Research exemplar diagram above, researchers need to specify: Specific Applied Problems (as they relate to User Requirements); Applied Research; Applied Knowledge; and Specific Applied Solutions (as thy relate to Interactive Systems).

These specifications require the extended Applied framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Applied design requires the Interactive System to do something (the Application) as desired (Performance). Applied Research acquires and validates Applied Knowledge to support Applied Design Practice.

The Applied Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Applied Applications

1.1 Objects

Applied applications (the ‘something’ the interactive system ‘does’) can be described as objects. Such applications occur in the need of organisations for interactive systems. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, an applied GUI e-mail application, favouring the recognition of text and images over the recall of commands (such as for correspondence), can be described for design research purposes in terms of objects; their abstract attributes, supporting the communication of messages; their physical attributes supporting the GUI visual/verbal representation of displayed information by means of language. Applied objects are specified as part of design and can be researched as such.

1.2 Attributes and Levels

The attributes of an applied application object emerge at different levels of description. For example, characters and their configuration on a GUI page are physical attributes of the object ‘e-mail,’ which emerge at one level. The message of the e-mail is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of innovation application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description.

1.4 Attribute States and Affordance

The attributes of applied application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a GUI e-mail (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

An applied application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The GUI object ‘book’ may be associated with the application of typesetting (state changes of its layout attributes) and with the application of authorship (state changes of its textual content). Such changes may constitute (part of) an applied design. In principle, an application may have any level of generality, for example, the writing of GUI personal e-mails and the writing of business e-mails. Object/attribute expression, as in the case of GUI e-mails, favours the recognition over the recall of command instructions.

Organisations have applications, which require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing to a friend’, each have a GUI e-mail as their transform, where the e-mails are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those e-mails produces additional state changes and therein, new transforms.

1.6 Application Goals

Organisations express the requirement for the transformation of applied application objects in terms of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal generally supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal. So, for example, the product goal demanding transformation of a GUI e-mail, making its message more courteous, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and of syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure, expressing the relations between task goals, for example, their sequences. The latter, favouring recognition over recall of command instructions, might constitute part of an applied design.

1.7 Innovation Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy the same product goal – GUI e-mails with different styles, for example, where different transforms exhibit different compromises between attribute state changes of the application object. There may also be transforms, which fail to meet the product goal. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of an application to be equated and evaluated. Such transforms may become the object of applied design and so research.

1.8 Applied Application and the User

Description of the applied application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, organisations express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’, which occurs only by means of objects, affording transformation and innovative interactive systems, capable of producing a transformation.

From product goals is derived a structure of related task goals, which can be assigned either to the user or to the interactive computer (or both) within the design of an associated interactive system. The task goals assigned to the user are those, which motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Applied Interactive Computers and the Human

2.1 Interactive Systems

Users are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Interactive computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all user and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a secretary and GUI electronic e-mail application, whose purpose is to manage correspondence, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of an interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The secretary and GUI e-mail application may transform the object ‘correspondence’ by changing both the attributes of its meaning and the attributes of its layout by means of recognised, as opposed to recalled, command instructions. More generally, an interactive system may transform an object through state changes, produced in related attributes.

The behaviours of the user and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the user does’, in contrast with ‘what is done’ (that is, attribute state changes of application objects). More precisely the user is described as:

a system of distinct and related user behaviours, identifiable as the sequence of states of a user interacting with a computer to do something as desired and corresponding with a purposeful (intentional) transformation of application objects.

Although expressible at many levels of description, the user must at least be described for design research purposes at a level, commensurate with the level of description of the transformation of innovation application objects. For example, a secretary interacting with a GUI electronic mail application is a user, whose behaviours include receiving and replying to messages by means of recognised, rather than recalled command instructions.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours, which extend a mutual influence – they are related. In particular, they are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a travel company secretary has the product goal, required to maintain the circulation of an electronic newsletter to customers. The secretary interacts with the computer by means of the innovative GUI interface (whose behaviours include the transmission of information about the newsletter). Hence, the secretary acquires a representation of the current circulation by collating the information displayed by the GUI screen and assessing it by comparison with the conditions, specified by the product goal. The secretary’s acquisition, collation, assessment and circulation of the newsletter are each distinct mental behaviours, described as representing and processing information. The secretary reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour, that is, recognising icons, rather than recalling and keying text-based commands – selecting GUI menu options.

The user is described as having cognitive, conative and affective aspects. The cognitive aspects are those of knowing, reasoning and remembering; the conative aspects are those of acting, trying and persevering; and the affective aspects are those of being patient, caring and assuring. Both mental and overt user behaviours are described as having these three aspects, all of which may contribute to ‘doing something, as desired wanted/needed/experienced/felt/valued.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems exert a ‘mutual influence’, that is to say they interact. Their configuration principally determines the interactive system and so its design and the associated research into that and other possible applied designs.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system.

Interaction of the user and the interactive computer behaviours is the fundamental determinant of the interactive system, rather than their individual behaviours per se. For example, the behaviours of a secretary interact with the behaviours of a GUI e-mail application. The secretary’s behaviours influence the behaviours of the interactive computer (selection of the dictionary function), while the behaviours of the interactive computer influence the selection behaviour of the operator (provision of possible correct spellings). The configuration of their interaction – the secretary’s selection of the dictionary function, the computer’s presentation of possible spelling corrections – determines the interactive system, comprising the secretary and interactive computer behaviours in their planning and control of correspondence. The interaction is the object of innovation design and so of design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of a mis-spelled word, required in a document is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the text field for the correctly spelled word demands an attribute state change in the text spacing of the document. Specifying that state change may be a task goal assigned to the user by recalled command instructions, as in interaction with the behaviours of early text editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the applied easily recognised GUI ‘wrap-round’ behaviours. Design research would be expected to have been involved in such innovations. The assignment of the expression of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human On-line and Off-line Behaviours

User behaviours may comprise both on-line and off-line behaviours: on-line behaviours are associated with the interactive computer’s representation of the application; off-line behaviours are associated with non-computer representations of the application.

As an illustration of the distinction, consider the example of an interactive system, consisting of the behaviours of a secretary and a a GUI e-mail application. They are required to produce a paper-based copy of a dictated letter, stored on audio tape. The product goal of the interactive system here requires the transformation of the physical representation of the letter from one medium to another, that is, from tape to paper. From the product goal derives the task goals, relating to required attribute state changes of the letter. Certain of those task goals will be assigned to the secretary. The secretary’s off-line behaviours include listening to and assimilating the dictated letter, so acquiring a representation of the application object. By contrast, the secretary’s on-line behaviours include specifying the represention by the interactive computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols by recognised menu options, rather than textual command instructions.

On-line and off-line user behaviours are a particular case of the ‘internal’ interactions between a user’s behaviours as, for example, when the secretary’s keying interacts with recalled memorisations of successive segments of the dictated letter.

2.5 Structures and the Human

Description of the user as a system of behaviours needs to be extended, for the purposes of design and design research, to the structures supporting that behaviour.

Whereas user behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘the support for the human to be able to do what they do’. There is a one-to-many mapping between a user’s structures and the behaviours they might support: thus, the same structures may support many different behaviours.

In co-extensively enabling behaviours at each level of description, structures must exist at commensurate levels. The user structural architecture is both physical and mental, providing the capability for a user’s overt and mental behaviours. It provides a represention of application information as symbols (physical and abstract) and concepts, and the processes available for the transformation of those representations. It provides an abstract structure for expressing information as mental behaviour. It provides a physical structure for expressing information as physical behaviour.

Physical user structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, user structure has cognitive, conative and affective aspects. The cognitive aspects of user structures include information and knowledge – that is, symbolic and conceptual representations – of the application, of the interactive computer and of the user themselves, and it includes the ability to reason. The conative aspects of user structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of user structures include the personality and temperament, which respond to and support behaviour. All three aspects may contribute to ‘ doing something, as desired wanted/needed/experienced/felt/valued’.

To illustrate this description of mental structure, consider the example of the structures supporting a secretary’s behaviours in an office. Physical structure supports perception of the GUI e-mail display and executing actions by means of recognition or recall to an electronic e-mail application. Mental structures support the acquisition, memorisation and transformation of information about how correspondence is conducted. The knowledge, which the operator has of the application and of the interactive computer, supports the collation, assessment and reasoning about the actions required.

The limits of user structures determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the application and the interactive computer; memory (recognition versus recall) and attentional capacities; patience; perseverence; dexterity; and visual acuity etc. The structural limits on behaviour may become particularly apparent, when one part of the structure (an attentional or memory channel capacity, perhaps) is required to support concurrent behaviours, perhaps simultaneous visual attending and reasoning behaviours. The user then, is ‘resource-limited’ by the co-extensive user structures.

The behavioural limits of the user, determined by structure, are not only difficult to define with any kind of completeness, they may also be variable, because that structure may change, and in a number of ways. A user may have self-determined changes in response to the application – as expressed in learning phenomena, acquiring new knowledge of the application, of the interactive computer, and indeed of themselves, to better support behaviour. Also, user structures degrade with the expenditure of resources by behaviour, as demonstrated by the phenomena of mental and physical fatigue. User structures may also change in response to motivating or de-motivating influences of the organisation, which maintains the interactive system.

It must be emphasised that the structure supporting the user is independent of the structure supporting the interactive computer behaviours. Neither structure can make any incursion into the other and neither can directly support the behaviours of the other. (Indeed this separability of structures is a pre-condition for expressing the interactive system as two interacting behavioural sub-systems). Although the structures may change in response to each other, they are not, unlike the behaviours they support, interactive; they are not included within the interactive system. The combination of structures of both user and interactive computer, supporting their interacting behaviours is described as the user interface .

2.6 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated directly with the user and distinguished as structural user costs and behavioural user costs.

Structural user costs are the costs of the user structures. Such costs are incurred in developing and maintaining user skills and knowledge. More specifically, structural user costs are incurred in training and educating users, so developing in them the structures, which will enable the behaviours necessary for an application . Recall of commands is considered to demand greater set-up costs than recognition of icons, for example. Training and educating may augment or modify existing structures, provide the user with entirely novel structures, or perhaps even reduce existing structures. Structural user costs will be incurred in each case and will frequently be borne by the organisation. An example of structural user costs might be the costs of training a secretary to use an innovative GUI interface in the particular style of layout, required for an organisation’s correspondence with its clients and in the operation of the interactive computer by which that layout style can be created.

Structural user costs may be differentiated as cognitive, conative and affective structural costs. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of users and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for ‘doing something as desired’. Conative structural costs express the costs of developing the activity, stamina and persistence of users as necessary for an application. Affective structural costs express the costs of developing in users their patience, care and assurance as necessary for an application.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of their of behaviours) in recruiting user structures to effect an application. They are both physical and mental resource costs. Physical behavioural costs are the costs of physical behaviours, for example, the costs of making keystrokes on a keyboard and of attending to a GUI screen display; they may be expressed without differentiation as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of  remembering (recognition or recall), knowing, reasoning, and deciding; they may be expressed without differentiation as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs. Costs are an important aspect of the design of an interactive computer system.

When differentiated, mental and physical behavioural costs are described as the cognitive, conative and affective behavioural costs of the user. Cognitive behavioural costs relate to both the mental representing and processing of information and the demands made on the user’s extant knowledge, as well as the physical expression thereof in the formulation and expression of a novel plan. Conative behavioural costs relate to the repeated mental and physical actions and effort, required by the formulation and expression of the novel plan. Affective behavioural costs relate to the emotional aspects of the mental and physical behaviours, required in the formulation and expression of the novel plan. Behavioural user costs are evidenced in user fatigue, stress and frustration; they are costs borne directly by the user and so need to be taken into account in the design process.

3. Performance of the Innovation Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued.

A concordance is assumed between the behaviours of an interactive system and its performance: behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer. Specifically, the resource costs incurred by the user are differentiated as: structural user costs – the costs of establishing and maintaining the structures supporting behaviour; and behavioural user costs – the costs of the behaviour, recruiting structure to its own support. Structural and behavioural user costs are further differentiated as cognitive, conative and affective costs. Design requires attention to all types of resource costs – both those of the user and of the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of design and so of design research.

Discriminating the user’s performance within the performance of the interactive system would require the separate assimilation of user resource costs and their achievement of desired attribute state changes, demanded by their assigned task goals. Further assertions concerning the user arise from the description of interactive system performance. First, the description of performance is able to distinguish the goodness of the transforms from the resource costs of the interactive system, which produce them. This distinction is essential for design, as two interactive systems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, it would be the lesser (in terms of performance) of the two systems.

Second, given the concordance of behaviour with ‘doing something as desired’, optimal user (and equally, interactive computer) behaviours may be described as those, which incur a (desired) minimum of resource costs in producing a given transform. Design of optimal user behaviour would minimise the resource costs (recognition being lower than recall), incurred in producing a transform of a given goodness. However, that optimality may only be categorically determined with regard to interactive system performance and the best performance of an interactive system may still be at variance with what is desired of it. To be more specific, it is not sufficient for user behaviours simply to be error-free. Although the elimination of errorful user behaviours may contribute to the best application possible of a given interactive system, that performance may still be less than ‘as desired’. Conversely, although user behaviours may be errorful, an interactive system may still support ‘doing something, as desired’.

Third, the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Fourth, structural and behavioural user costs may be traded-off in the design of an application. More sophisticated user structures, supporting user behaviours, that is, the knowledge and skills of experienced and trained users, will incur high (structural) costs to develop, but enable more efficient behaviours – and therein, reduced behavioural costs.

Fifth, resource costs, incurred by the user and the interactive computer may be traded-off in the design of the performance of an application. A user can sustain a level of performance of the interactive system by optimising behaviours to compensate for the poorly designed behaviours of the interactive computer (and vice versa), that is, behavioural costs of the user and interactive computer are traded-off in the design process. This is of particular importance as the ability of users to adapt their behaviours to compensate for the poor design of interactive computer-based systems often obscures the fact that the systems are poorly designed.

Requirement 1: The framework (as a basic support structure) is for a discipline (as an academic field of study and branch of knowledge).

The paper makes clear that Cognitive Theory forms part of the discipline of Psychology, which in turn seeks to be a Science. Psychology is assumed to be an academic discipline with its own field of study (Comments 1, 2, 4, 6, 9, 14). Cognitive theory can be applied to the design of human-computer interactions. HCI is considered to be its domain of application (Comments 4, 5,and 6). Cognitive Theory informs Cognitive Engineering. Both inform design (Comment 21). It is unclear that HCI design itself is, here, considered to be a discipline in its own right and if so, of what kind.

Requirement 2: The framework is for HCI (as human-computer interaction) as applied (as prescription) design.

The paper describes the  application of Cognitive Theory to the design of humans interacting with computers in tasks such as text editing, document preparation etc (Comments 12 and 13). Application may be direct or indirect in the form of models of the user or analytic deductions from theory respectively (Comments 24, 25 and 26). Given the type of paper, lower levels of description of the framework are unsurprisingly not presented.

Requirement 3: The framework has a general problem (as applied design) with a particular scope (as human computer interactions to do something as desired).

The paper espouses the concept of HCI as science with the general problem of understanding (Comment 1). Cognitive Theory is intended to be applied to the design of humans interacting with computers (Comments 12 and 13). Tasks are performed as needed and required by the end-user (Comment 7). Such performance may be expressed in terms of time and errors (Comment 10).

Requirement 4: Research ( as acquisition and validation) acquires (as study and practice) and validates (as confirms) knowledge (as theories; models; laws; data; hypotheses; analytical and empirical methods and tools).

The paper makes frequent reference to the scientific research needed to acquire Cognitive Theory (Comment 8). Research produces and uses: theories; models; data; hypotheses; and empirical methods (Comments 3, 8 and 11). Cognitive Theories require verification (and validation) (Comment 9).

Requirement 5: This knowledge supports (facilitates) practices (as explanation and prediction), which solve (as resolve) the general problem of understanding.

The paper proposes that Cognitive Theory, as Psychology discipline knowledge, is able to support the understanding of phenomena, associated with humans interacting with computers (Comment 2). This understanding can be applied to HCI design by means of Cognitive Theory (Comments 12 and 13). The practices of understanding, such as explanation and prediction, of such phenomena received little or no attention; but are assumed to be involved in the support provided by understanding. Little or no reference is made to the different types of HCI design practice.

Conclusion: Barnard’s paper obviously espouses the concept of HCI, as applied science and in particular the application of Psychology in the form of Cognitive Theory to the design of humans interacting with computers. The framework is more-or-less complete at a high level of description with its references to understanding, models and methods. As a review/essay-type paper it understandably reports no detailed design research. To do so the framework would need to be expressed at lower levels of description to instantiate the models and methods of Cognitive Theory in the service of the practices of design, that is, the diagnosis of design problems and the prescription of design solutions. To this end, the framework would need to be expressed at lower levels of description. The detailed frameworks proposed here might be useful in this respect.

Discipline

Innovation – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Art – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Craft – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Applied – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Science – Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Engineering – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI

Innovation – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Art – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Craft – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Applied – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Science – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Engineering – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Framework Type

Innovation – Innovation: novel (novel – new ideas/methods/devices etc)

Art – Art: creative expression corresponding to some ideal or criteria (creative – imaginative, inventive); (expressive – showing by taking some form); ideal – visionary/perfect); criterion – standard).

Craft – Craft: best practice design (practice – design/evaluation; design – specification/implementation).

Applied – Applied: application of other discipline knowledge (application – addition to/prescription; discipline – academic field/branch of knowledge; knowledge – information/learning).

Science – understanding (explanation/prediction)

Engineering – design for performance (design – specification/implementation; performance – how well effected).

General Problem

Innovation – innovation design (innovation – novelty; design – specification/implementation).

Art – art design (art – ideal creative expression; design – specification/implementation).

Craft – craft design (craft – best practice; design – specification/implementation).

Applied – applied design (applied – added/prescribed; design – specification/implementation).

Science – understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

Engineering – engineering design (engineering – design for performance; design – specification/implementation).

Particular Scope

Innovation – innovative human-computer interactions to do something as desired (innovative – novel; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued).

Art – art human-computer interactions to do something as desired (art – creation/expression; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task); desired: wanted/needed/experienced/felt/valued).

Craft – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Applied – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Science – human-computer interactions to do something as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued.

Engineering – human-computer interactions to perform tasks effectively as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; perform – effect/carry out; tasks – actions; desired – wanted/needed/experienced/felt/valued).

Research

Innovation – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – patents/expert advice/experience/examples).

Art – acquires and validates knowledge (acquires – creates by study/practice; validates – confirms; knowledge – experience/expert advice/other artefacts.

Craft – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Science – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools; practices – explanation/prediction).

Engineering – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Knowledge

Innovation – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Art – supports practices (supports – facilitates/makes possible; practices – trial and error/implement and test).

Craft – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Applied – supports practices (supports – facilitates/makes possible; practices – trial-and-error/apply and test).

Science – supports practices (supports – facilitates/makes possible; practices – explanation/prediction).

Engineering – supports practices (supports – facilitates/makes possible; practices – diagnose design problems/prescribe design solutions).

Practices

Innovation – supported by knowledge (supported – facilitated; knowledge – patents/expert advice/experience/examples).

Art – supported by knowledge (supported – facilitated/made possible; knowledge – experience/expert advice/other artefacts).

Craft – supported by knowledge (supported – facilitated; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – supported by knowledge (supported – facilitated; knowledge – guidelines; heuristics/methods/expert advice/successful designs/case-studies).

Science – supported by knowledge (supported – facilitated; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools ).

Engineering – supported by knowledge (supported – facilitated; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Solution

Innovation – resolution of a problem (resolution – answer/address; problem – question/doubt).

Art – resolution of the general problem (resolution – answer/address; problem – question/doubt).

Craft – resolution of a problem (resolution – answer/address; problem – question/doubt).

Applied – resolution of a problem (resolution – answer/address; problem – question/doubt).

Science – resolution of a problem (resolution – answer/address; problem – question/doubt).

Engineering – resolution of a problem (resolution – answer/address; problem – question/doubt).

The initial framework for a science approach to HCI follows. The key concepts appear in bold.

The framework for a discipline of HCI as science has a general problem with a particular scope. Research acquires and validates knowledge, which supports practices, solving the general problem.

Key concepts are defined below (with additional clarification in brackets).

Framework: a basic supporting structure (basic – fundamental; supporting – facilitating/making possible; structure – organisation).

Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI: human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Science: understanding (explanation/prediction)

General Problem: understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

Particular Scope: human-computer interactions to do something as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued.

Research: acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools; practices – explanation/prediction).

Knowledge: supports practices (supports – facilitates/makes possible; practices – explanation/prediction).

Practices: supported by knowledge (supported – facilitated; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools ).

Solution: resolution of a problem (resolution – answer/address; problem – question/doubt).

General Problem: understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

This framework for a discipline of HCI as science is more complete, coherent and fit-for-purpose than the description afforded by the science approach to HCI (see earlier). The framework thus better supports thinking about and doing science HCI. As the framework is explicit, it can be shared by all interested researchers. Once shared, it enables researchers to build on each other’s work. This sharing and building is further supported by a re-expression of the framework, as a design research exemplar. The latter specifies the complete design research cycle, which once implemented constitutes a case-study of an of a science approach to HCI. The diagram, which follows, presents the science design research exemplar.

For researchers who conduct both Applied and Science design research, the two design research exemplars may be usefully combined, as follows:

Key: Science Knowledge – theories; models; laws; data; hypotheses; analytical and empirical methods; tools. EP – Empirical Practice EK – Empirical Knowledge FP – Formal Practice FK – Formal Knowledge

Key: Applied Knowledge – guidelines; heuristics; methods; expert advice; successful designs; case-studies. EP – Empirical Practice EK – Empirical Knowledge

         Design Research Exemplar – HCI as Applied and as Science Combined

Examples of such levels are presented here – first a short version and then a long version. Researchers, of course, might have their own lower level descriptions or subscribe to some more generally recognised levels. Such descriptions are acceptable, as long as they fit with the higher level descriptions of the framework and are complete; coherent and fit-for-purpose. In the absence of alternative levels of description, researchers might try the short version first .

These levels go, for example from ‘human’ to ‘user’ and from ‘computer’ to ‘interactive system’. The lowest level, of course, needs to reference the science phenomena to be understood, in terms of the application, for example, for a business interactive system, phenomena, associated with the secretary and the electronic mailing facility. Researchers are encouraged to select from the framework extensions as required and to add the lowest level description, relevant to their research. The lowest level is used here to illustrate the extended science framework.

Following the Science Design Research exemplar diagram above, researchers need to specify: Specific Science Problems (as they relate to Specific Applied Problems and User Requirements); Science Research; Science Knowledge; and Specific Science Solutions (as thy relate to Specific Applied Solutions and Interactive Systems).

These specifications require the extended science framework to include in the scope of its phenomena to be understood: the Application; the Interactive System; and Performance, relating the former to the latter. Science-based design requires the Interactive System to do something (the Application) as desired (Performance). Science Research acquires and validates Applied Knowledge to support Science Practices of explanation and prediction of phenomena, which together constitute understanding thereof.

The Science Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Science Applications

1.1 Objects

Science applications (the ‘ something’, which the interactive system does) can be described in terms of objects. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, phenomena, associated with a GUI e-mail application, favouring the recognition of text and images over the recall of commands (such as for correspondence), can be described for design-based science research purposes in terms of objects; their abstract attributes, supporting the communication of messages; their physical attributes supporting the GUI visual/verbal representation of displayed information by means of language. Science objects are specified as part of the phenomena to be explained and predicted and so understood and can be researched as such.

1.2 Attributes and Levels

The attributes of a science application object emerge at different levels of description. For example, characters and their configuration on a GUI page are physical attributes of the object ‘e-mail,’ which emerge at one level. The message of the e-mail is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of science application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description. Such relations are specified as part of science-based design.

1.4 Attribute States and Affordance

The attributes of science application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a science GUI e-mail (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

A science application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The GUI object ‘book’ may be associated with the application of typesetting (state changes of its layout attributes) and with the application of authorship (state changes of its textual content). In principle, an application may have any level of generality, for example, the writing of GUI personal e-mails and the writing of business e-mails. Object/attribute expression, as in the case of GUI e-mails, favours the recognition over the recall of command instructions. The documentation of the associated recognition/recall phenomena, their explanation and prediction by science theory, constituting understanding thereof, all comprise the goals of science research.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing to a friend’, each have a GUI e-mail as their transform, where the e-mails are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those e-mails would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute a Specific Applied Problem and so a Specific Science Problem and lead to a new design, which embodies a Specific Applied Solution, derived from a Specific Science Solution.

1.6 Application Goals

The requirement for the transformation of science application objects is expressed in the form of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a GUI e-mail, making its message more courteous, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and of syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter, favouring recognition over recall of command instructions, might constitute part of applied design, based on science knowledge.

1.7 Science Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – GUI e-mails with different styles. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal. Such transforms may become the object of applied design and so of science research.

1.8 Science Application and the User

One description of the science application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, users express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’.

From product goals is derived a structure of related task goals, which can be assigned, by design practice, either to the user or to the interactive computer (or both) within an associated interactive system. Task goals assigned to the user by the science-based design are those, intended to motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2. Science Interactive Computers

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a secretary and GUI electronic e-mail application, whose purpose is to conduct correspondence, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched, as set of associated phenomena.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The secretary and GUI e-mail application may transform the object ‘correspondence’ by changing both the attributes of its meaning and the attributes of its layout by means of recognised, as opposed to recalled command instructions, as derived from science knowledge.

The behaviours of the human and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the human does’, in contrast with ‘what is done’ (i.e. attribute state changes of application objects). Science provides a more specific understanding, in terms of the explanation and prediction of the relevant phenomena.

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a secretary interacting with an GUI electronic mail application is a user, whose behaviours include receiving and replying to messages by means of recognised, rather than recalled command instructions, as derived from science knowledge.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours. They are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine, and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a travel company secretary has the product goal, required to maintain the circulation of an electronic newsletter to customers. The secretary interacts with the computer by means of the applied GUI interface (whose behaviours include the icon-based transmission of information about the newsletter). Hence, the secretary acquires a representation of the current circulation by collating the information displayed by the GUI screen and assessing it by comparison with the conditions, specified by the product goal. The secretary reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour, that is, recognising icons, rather than recalling and keying text-based commands – selecting GUI menu options, as prompted by science research.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems extert a ‘mutual influence’ or interaction. Their configuration principally determines the interactive system and science-based design and research.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a secretary interact with the behaviours of a GUI e-mail application. The secretary’s behaviours influence the behaviours of the interactive computer (access the dictionary function), while the behaviours of the interactive computer influence the selection behaviour of the operator (among possible correct spellings). The design of their interaction – the secretary’s selection of the dictionary function, the computer’s presentation of possible spelling corrections – determines the interactive system, comprising the secretary and interactive computer behaviours in their planning and control of correspondence. The interaction may be the object of science-based design, favouring recognition over recall and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of a mis-spelled word, required in a document is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the text field for the correctly spelled word demands an attribute state change in the text spacing of the document. Specifying that state change may be a task goal assigned to the user by recalled command instructions, as in interaction with the behaviours of early text editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the applied easily recognised GUI ‘wrap-round’ behaviours. Science research aims to inform such design, albeit indirectly, by seeking to understand, that is explain and predict, associated phenomena. The assignment of the expression of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of science research.

2.4 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated with the user and distinguished as behavioural user costs.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of behaviours) to effect an application. They are both physical and mental. Physical costs are those of physical behaviours, for example, the costs of keying or of attending the GUI menu options; they may be expressed for science-based design purposes as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed for science-based design purposes as mental workload. Recognition behavioural costs, for example, have been shown by science research to be lower that those of recall behaviours. Reflection thereof is assumed to be mirrored by the popularity of GUI interfaces. Mental behavioural costs are ultimately manifest as physical behavioural costs, for example, menu option selection or text input keying.

3. Performance of the Applied Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued. Desired performance is the object of applied design and is assumed to be derivable from science knowledge.

Behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of design and so of applied design research and so of science research.

The common measures of human ‘performance’ – errors and time, are related in this notion of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Following the Science Design Research exemplar diagram above, researchers need to specify: Specific Science Problems (as they relate to Specific Applied Problems and to User Requirements); Science Research; Science Knowledge; and Specific Science Solutions (as they relate to Specific Applied Solutions and to Interactive Systems).

These specifications require the extended science framework to include in the scope of its phenomena to be understood: the Application; the Interactive System; and Performance, relating the former to the latter. Science-based design requires the Interactive System to do something (the Application) as desired (Performance). Science Research acquires and validates Applied Knowledge to support Science Practices of explanation and prediction of phenomena, which together constitute understanding thereof.

The Science Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Science Applications

1.1 Objects

Science applications (the ‘something’ the interactive system ‘does’) can be described as objects. Such applications occur in the need of organisations for interactive systems. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, phenomena, associated with a GUI e-mail application, favouring the recognition of text and images over the recall of commands (such as for correspondence), can be described for design-based science research purposes in terms of objects; their abstract attributes, supporting the communication of messages; their physical attributes supporting the GUI visual/verbal representation of displayed information by means of language. Science objects are specified as part of the phenomena to be explained and predicted and so understood and can be researched as such.

1.2 Attributes and Levels

The attributes of a science-based application object emerge at different levels of description. For example, characters and their configuration on a GUI page are physical attributes of the object ‘e-mail,’ which emerge at one level. The message of the e-mail is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of science application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description.

1.4 Attribute States and Affordance

The attributes of science application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a GUI e-mail (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

A science application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The GUI object ‘book’ may be associated with the application of typesetting (state changes of its layout attributes) and with the application of authorship (state changes of its textual content). In principle, an application may have any level of generality, for example, the writing of GUI personal e-mails and the writing of business e-mails. Object/attribute expression, as in the case of GUI e-mails, favours the recognition over the recall of command instructions. The documentation of the associated recognition/recall phenomena, their explanation and prediction by science theory, constituting understanding thereof, all comprise the goals of science research.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing to a friend’, each have a GUI e-mail as their transform, where the e-mails are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those e-mails would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute a Specific Applied Problem and so a Specific Science Problem and lead to a new design, which embodies a Specific Applied Solution, derived from a Specific Science Solution.

1.6 Application Goals

Organisations express the requirement for the transformation of applied application objects in terms of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal generally supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal. So, for example, the product goal demanding transformation of a GUI e-mail, making its message more courteous, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and of syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure, expressing the relations between task goals, for example, their sequences. The latter, favouring recognition over recall of command instructions, might constitute part of applied research, derived from science knowledge.

1.7 Science Application as: Doing Something as Desired

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy the same product goal – GUI e-mails with different styles, for example, where different transforms exhibit different compromises between attribute state changes of the application object. There may also be transforms, which fail to meet the product goal. The concept of ‘doing something as desired’ describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of an application to be equated and evaluated. Such transforms may become the object of applied design and so of science research.

1.8 Science Application and the User

Description of the science application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, organisations express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘doing something, as desired’, which occurs only by means of objects, affording transformation and  interactive systems, capable of producing a transformation.

From product goals is derived a structure of related task goals, which can be assigned, by design practice, either to the user or to the interactive computer (or both) within an associated interactive system. Task goals assigned to the user by the science-based design are those, intended to motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2. Science Interactive Computers and the Human

2.1 Interactive Systems

Users are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Interactive computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all user and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a secretary and GUI electronic e-mail application, whose purpose is to manage correspondence, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of an interactive system can be established and so designed and researched, as a set of associated phenomena.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The secretary and GUI e-mail application may transform the object ‘correspondence’ by changing both the attributes of its meaning and the attributes of its layout by means of recognised, as opposed to recalled, command instructions, as derived from science knowledge. More generally, an interactive system may transform an object through state changes, produced in related attributes.

The behaviours of the user and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the user does’, in contrast with ‘what is done’ (that is, attribute state changes of application objects). More precisely the user is described as:

a system of distinct and related user behaviours, identifiable as the sequence of states of a user interacting with a computer to do something as desired and corresponding with a purposeful (intentional) transformation of application objects.

Although expressible at many levels of description, the user must at least be described for science-based design research purposes at a level, commensurate with the level of description of the transformation of application objects. For example, a secretary interacting with a GUI electronic mail application is a user, whose behaviours include receiving and replying to messages by means of recognised, rather than recalled command instructions.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours, which extend a mutual influence – they are related. In particular, they are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a travel company secretary has the product goal, required to maintain the circulation of an electronic newsletter to customers. The secretary interacts with the computer by means of the applied GUI interface (whose behaviours include the icon-based transmission of information about the newsletter). Hence, the secretary acquires a representation of the current circulation by collating the information displayed by the GUI screen and assessing it by comparison with the conditions, specified by the product goal. The secretary reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour, that is, recognising icons, rather than recalling and keying text-based commands – selecting GUI menu options, as prompted by science research.

The user is described as having cognitive, conative and affective aspects. The cognitive aspects are those of knowing, reasoning and remembering (for example, recognition and recall); the conative aspects are those of acting, trying and persevering; and the affective aspects are those of being patient, caring and assuring. Both mental and overt user behaviours are described as having these three aspects, all of which may contribute to ‘doing something, as desired wanted/needed/experienced/felt/valued.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems exert a ‘mutual influence’, that is to say they interact. Their configuration principally determines the interactive system and so its design and the associated science research into that and other possible associated design phenomena.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system.

Interaction of the user and the interactive computer behaviours is the fundamental determinant of the interactive system, rather than their individual behaviours per se. For example, the behaviours of a secretary interact with the behaviours of a GUI e-mail application. The secretary’s behaviours influence the behaviours of the interactive computer (selection of the dictionary function), while the behaviours of the interactive computer influence the selection behaviour of the operator (provision of possible correct spellings). The configuration of their interaction – the secretary’s selection of the dictionary function, the computer’s presentation of possible spelling corrections – determines the interactive system, comprising the secretary and interactive computer behaviours in their planning and control of correspondence. The interaction is the object of applied design and so of related science research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of a mis-spelled word, required in a document is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the text field for the correctly spelled word demands an attribute state change in the text spacing of the document. Specifying that state change may be a task goal assigned to the user by recalled command instructions, as in interaction with the behaviours of early text editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the applied easily recognised GUI ‘wrap-round’ behaviours. Design research would be expected to have been involved in such innovations. The assignment of the expression of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of science research.

2.4 Human On-line and Off-line Behaviours

User behaviours may comprise both on-line and off-line behaviours: on-line behaviours are associated with the interactive computer’s representation of the application; off-line behaviours are associated with non-computer representations of the application.

As an illustration of the distinction, consider the example of an interactive system, consisting of the behaviours of a secretary and a a GUI e-mail application. They are required to produce a paper-based copy of a dictated letter, stored on audio tape. The product goal of the interactive system here requires the transformation of the physical representation of the letter from one medium to another, that is, from tape to paper. From the product goal derives the task goals, relating to required attribute state changes of the letter. Certain of those task goals will be assigned to the secretary. The secretary’s off-line behaviours include listening to and assimilating the dictated letter, so acquiring a representation of the application object. By contrast, the secretary’s on-line behaviours include specifying the represention by the interactive computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols by recognised menu options, rather than textual command instructions. Associated phenomena could be the object of science understanding and so research.

On-line and off-line user behaviours are a particular case of the ‘internal’ interactions between a user’s behaviours as, for example, when the secretary’s keying interacts with recalled memorisations of successive segments of the dictated letter.

2.5 Structures and the Human

Description of the user as a system of behaviours needs to be extended, for the purposes of science-based design and design research, to the structures supporting that behaviour.

Whereas user behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘the support for the human to be able to do what they do’. There is a one-to-many mapping between a user’s structures and the behaviours they might support: thus, the same structures may support many different behaviours.

In co-extensively enabling behaviours at each level of description, structures must exist at commensurate levels. The user structural architecture is both physical and mental, providing the capability for a user’s overt and mental behaviours. It provides a represention of application information as symbols (physical and abstract) and concepts, and the processes available for the transformation of those representations. It provides an abstract structure for expressing information as mental behaviour. It provides a physical structure for expressing information as physical behaviour.

Physical user structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, user structure has cognitive, conative and affective aspects. The cognitive aspects of user structures include information and knowledge – that is, symbolic and conceptual representations – of the application, of the interactive computer and of the user themselves, and it includes the ability to reason. The conative aspects of user structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of user structures include the personality and temperament, which respond to and support behaviour. All three aspects may contribute to ‘ doing something, as desired wanted/needed/experienced/felt/valued’.

To illustrate this description of mental structure, consider the example of the structures supporting a secretary’s behaviours in an office. Physical structure supports perception of the GUI e-mail display and executing actions by means of recognition or recall to an electronic e-mail application. Mental structures support the acquisition, memorisation and transformation of information about how correspondence is conducted. The knowledge, which the operator has of the application and of the interactive computer, supports the collation, assessment and reasoning about the actions required.

The limits of user structures determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the application and the interactive computer; memory (recognition versus recall) and attentional capacities; patience; perseverence; dexterity; and visual acuity etc. The structural limits on behaviour may become particularly apparent, when one part of the structure (an attentional or memory channel capacity, perhaps) is required to support concurrent behaviours, perhaps simultaneous visual attending and reasoning behaviours. The user then, is ‘resource-limited’ by the co-extensive user structures. Such phenomena have been widely researched by science and various levels of understanding achieved.

The behavioural limits of the user, determined by structure, are not only difficult to define with any kind of completeness, they may also be variable, because that structure may change, and in a number of ways. A user may have self-determined changes in response to the application – as expressed in learning phenomena, acquiring new knowledge of the application, of the interactive computer, and indeed of themselves, to better support behaviour. Also, user structures degrade with the expenditure of resources by behaviour, as demonstrated by the phenomena of mental and physical fatigue. User structures may also change in response to motivating or de-motivating influences of the organisation, which maintains the interactive system.

It must be emphasised that the structure supporting the user is independent of the structure supporting the interactive computer behaviours. Neither structure can make any incursion into the other and neither can directly support the behaviours of the other. (Indeed this separability of structures is a pre-condition for expressing the interactive system as two interacting behavioural sub-systems). Although the structures may change in response to each other, they are not, unlike the behaviours they support, interactive; they are not included within the interactive system. The combination of structures of both user and interactive computer, supporting their interacting behaviours is described as the user interface .

2.6 Human Resource Costs

‘Doing something as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated directly with the user and distinguished as structural user costs and behavioural user costs.

Structural user costs are the costs of the user structures. Such costs are incurred in developing and maintaining user skills and knowledge. More specifically, structural user costs are incurred in training and educating users, so developing in them the structures, which will enable the behaviours necessary for an application . Recall of commands is considered to demand greater set-up costs than recognition of icons, for example. Training and educating may augment or modify existing structures, provide the user with entirely novel structures, or perhaps even reduce existing structures. Structural user costs will be incurred in each case and will frequently be borne by the organisation. An example of structural user costs might be the costs of training a secretary to use an innovative GUI interface in the particular style of layout, required for an organisation’s correspondence with its clients and in the operation of the interactive computer by which that layout style can be created.

Structural user costs may be differentiated as cognitive, conative and affective structural costs. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of users and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for ‘doing something as desired’. Conative structural costs express the costs of developing the activity, stamina and persistence of users as necessary for an application. Affective structural costs express the costs of developing in users their patience, care and assurance as necessary for an application.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of their of behaviours) in recruiting user structures to effect an application. They are both physical and mental resource costs. Physical behavioural costs are the costs of physical behaviours, for example, the costs of making keystrokes on a keyboard and of attending to a GUI screen display; they may be expressed without differentiation as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of remembering (recognition or recall), knowing, reasoning, and deciding; they may be expressed without differentiation as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs. Costs are an important aspect of the design of an interactive computer system.

When differentiated, mental and physical behavioural costs are described as the cognitive, conative and affective behavioural costs of the user. Cognitive behavioural costs relate to both the mental representing and processing of information and the demands made on the user’s extant knowledge, as well as the physical expression thereof in the formulation and expression of a novel plan. Conative behavioural costs relate to the repeated mental and physical actions and effort, required by the formulation and expression of the novel plan. Affective behavioural costs relate to the emotional aspects of the mental and physical behaviours, required in the formulation and expression of the novel plan. Behavioural user costs are evidenced in user fatigue, stress and frustration; they are costs borne directly by the user and so need to be taken into account in the design process.

3. Performance of the Innovation Interactive Computer System and the User.

‘To do something as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘doing something as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued.

A concordance is assumed between the behaviours of an interactive system and its performance: behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer. Specifically, the resource costs incurred by the user are differentiated as: structural user costs – the costs of establishing and maintaining the structures supporting behaviour; and behavioural user costs – the costs of the behaviour, recruiting structure to its own support. Structural and behavioural user costs are further differentiated as cognitive, conative and affective costs. Design requires attention to all types of resource costs – both those of the user and of the interactive computer.

‘Doing something as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of design and so of design research.

Discriminating the user’s performance within the performance of the interactive system would require the separate assimilation of user resource costs and their achievement of desired attribute state changes, demanded by their assigned task goals. Further assertions concerning the user arise from the description of interactive system performance. First, the description of performance is able to distinguish the goodness of the transforms from the resource costs of the interactive system, which produce them. This distinction is essential for design, as two interactive systems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, it would be the lesser (in terms of performance) of the two systems.

Second, given the concordance of behaviour with ‘doing something as desired’, optimal user (and equally, interactive computer) behaviours may be described as those, which incur a (desired) minimum of resource costs in producing a given transform. Design of optimal user behaviour would minimise the resource costs (recognition being lower than recall), incurred in producing a transform of a given goodness. However, that optimality may only be categorically determined with regard to interactive system performance and the best performance of an interactive system may still be at variance with what is desired of it. To be more specific, it is not sufficient for user behaviours simply to be error-free. Although the elimination of errorful user behaviours may contribute to the best application possible of a given interactive system, that performance may still be less than ‘as desired’. Conversely, although user behaviours may be errorful, an interactive system may still support ‘doing something, as desired’.

Third, the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Fourth, structural and behavioural user costs may be traded-off in the design of an application. More sophisticated user structures, supporting user behaviours, that is, the knowledge and skills of experienced and trained users, will incur high (structural) costs to develop, but enable more efficient behaviours – and therein, reduced behavioural costs.

Fifth, resource costs, incurred by the user and the interactive computer may be traded-off in the design of the performance of an application. A user can sustain a level of performance of the interactive system by optimising behaviours to compensate for the poorly designed behaviours of the interactive computer (and vice versa), that is, behavioural costs of the user and interactive computer are traded-off in the design process. This is of particular importance as the ability of users to adapt their behaviours to compensate for the poor design of interactive computer-based systems often obscures the fact that the systems are poorly designed.

Requirement 1: The framework (as a basic support structure) is for a discipline (as an academic field of study and branch of knowledge).

Barnard makes clear that Cognitive Theory forms part of the discipline of Psychology, which in turn seeks to be a Science. Psychology is is assumed to be an academic discipline with its own field of study. See Comments 1, 4, 5 and 12. Cognitive theory can be applied to the design of human-computers interactions. See Comments 4, 6, 7 and 12.

Requirement 2: The framework is for HCI (as human-computer interaction), as science (as understanding).

Barnard makes clear that the aim of Science/Psychology/ Cognitive Theory is understanding the phenomena of humans interacting with computers, for example the selection among choices, trading off speed for errors etc.

Requirement 3: The framework has a general problem (as scientific understanding) with a particular scope (as human computer interactions to do something as desired).

The paper espouses the concept of HCI as science (Comment 1). Tasks are performed as needed and required by the end-user (Comment 7). Such performance may be expressed in terms of time and errors and time Comment 10).

Requirement 4: Research ( as acquisition and validation) acquires (as study and practice) and validates (as confirms) knowledge (as theories; models; laws;data; hypotheses; analytical and empirical methods and tools).

Barnard makes frequent reference to the scientific research needed to acquire Cognitive Theory (Comment 8). Research produces and uses: theories; models; data; hypotheses; and empirical methods (Comments 3, 8 and 11). Cognitive Theories require verification (and validation) Comment 9).

Requirement 5: This knowledge supports (facilitates) practices (as explanation and prediction), which solve (as resolve) the general problem of understanding.

Barnard claims that Cognitive Theory, as Psychology discipline knowledge, is able to support the understanding of phenomena, associated with humans interacting with computers (Comment 2). The practices of understanding, such as explanation and prediction, of such phenomena received little or no emphasis.

Conclusion:

Barnard’s paper obviously espouses the concept of HCI, as science and in particular the science of Psychology in the form of Cognitive Theory. The framework is more-or-less complete at a high level of description with its references to understanding, models and methods. As a review/essay-type paper it understandably reports no detailed research. To do so the framework would need to be expressed at lower levels of description to instantiate the models and methods of Cognitive Theory in the service of the practices of understanding, that is, explanation and prediction. To this end, the framework would need to be expressed at lower levels of description, as proposed here.

Discipline

Innovation – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Art – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Craft – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Applied – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Science – Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Engineering – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI

Innovation – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Art – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Craft – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Applied – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Science – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Engineering – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Framework Type

Innovation – Innovation: novel (novel – new ideas/methods/devices etc)

Art – Art: creative expression corresponding to some ideal or criteria (creative – imaginative, inventive); (expressive – showing by taking some form); ideal – visionary/perfect); criterion – standard).

Craft – Craft: best practice design (practice – design/evaluation; design – specification/implementation).

Applied – Applied: application of other discipline knowledge (application – addition to/prescription; discipline – academic field/branch of knowledge; knowledge – information/learning).

Science – understanding (explanation/prediction)

Engineering – design for performance (design – specification/implementation; performance – how well effected).

General Problem

Innovation – innovation design (innovation – novelty; design – specification/implementation).

Art – art design (art – ideal creative expression; design – specification/implementation).

Craft – craft design (craft – best practice; design – specification/implementation).

Applied – applied design (applied – added/prescribed; design – specification/implementation).

Science – understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

Engineering – engineering design (engineering – design for performance; design – specification/implementation).

Particular Scope

Innovation – innovative human-computer interactions to do something as desired (innovative – novel; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued).

Art – art human-computer interactions to do something as desired (art – creation/expression; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task); desired: wanted/needed/experienced/felt/valued).

Craft – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Applied – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Science – human-computer interactions to do something as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued.

Engineering – human-computer interactions to perform tasks effectively as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; perform – effect/carry out; tasks – actions; desired – wanted/needed/experienced/felt/valued).

Research

Innovation – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – patents/expert advice/experience/examples).

Art – acquires and validates knowledge (acquires – creates by study/practice; validates – confirms; knowledge – experience/expert advice/other artefacts.

Craft – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Science – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools; practices – explanation/prediction).

Engineering – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Knowledge

Innovation – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Art – supports practices (supports – facilitates/makes possible; practices – trial and error/implement and test).

Craft – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Applied – supports practices (supports – facilitates/makes possible; practices – trial-and-error/apply and test).

Science – supports practices (supports – facilitates/makes possible; practices – explanation/prediction).

Engineering – supports practices (supports – facilitates/makes possible; practices – diagnose design problems/prescribe design solutions).

Practices

Innovation – supported by knowledge (supported – facilitated; knowledge – patents/expert advice/experience/examples).

Art – supported by knowledge (supported – facilitated/made possible; knowledge – experience/expert advice/other artefacts).

Craft – supported by knowledge (supported – facilitated; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – supported by knowledge (supported – facilitated; knowledge – guidelines; heuristics/methods/expert advice/successful designs/case-studies).

Science – supported by knowledge (supported – facilitated; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools ).

Engineering – supported by knowledge (supported – facilitated; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Solution

Innovation – resolution of a problem (resolution – answer/address; problem – question/doubt).

Art – resolution of the general problem (resolution – answer/address; problem – question/doubt).

Craft – resolution of a problem (resolution – answer/address; problem – question/doubt).

Applied – resolution of a problem (resolution – answer/address; problem – question/doubt).

Science – resolution of a problem (resolution – answer/address; problem – question/doubt).

Engineering – resolution of a problem (resolution – answer/address; problem – question/doubt).

This framework for a discipline of HCI as engineering is more complete, coherent and fit-for-purpose than the description afforded by the engineering approach to HCI (see earlier). The framework thus better supports thinking about and doing engineering HCI. As the framework is explicit, it can be shared by all interested researchers. Once shared, it enables researchers to build on each other’s work. This sharing and building is further supported by a re-expression of the framework, as a design research exemplar. The latter specifies the complete design research cycle, which once implemented constitutes a case-study of an of an engineering approach to HCI. The diagram, which follows, presents the engineering design research exemplar.

Examples of such levels are presented here – first a short version and then a long version. Researchers, of course, might have their own lower level descriptions or subscribe to some more generally recognised levels. Such descriptions are acceptable, as long as they fit with the higher level descriptions of the framework and are complete; coherent and fit-for-purpose. In the absence of alternative levels of description, researchers might try the short version first .

These levels go, for example from ‘human’ to ‘user’ and from ‘computer’ to ‘interactive system’. The lowest level, of course, needs to reference the application, in terms of the application itself but also the interactive system. Researchers are encouraged to select from the framework extensions as required and to add the lowest level description, relevant to their research. The lowest level is used here to illustrate the extended engineering framework.

Following the Engineering Design Research exemplar diagram, researchers need to specify:

• User Requirements (unsatisfied) and Interactive System;
• Design Problem and Design Solution for design guidelines/models and methods Engineering Knowledge;
• Specific Principle Design Problem and Specific Principle Design Solution for Specific Substantive and Methodological Principle Engineering Knowledge;
•  General Principle Design Problem and General Principle Design Solution for General Substantive and Methodological Principle Engineering Knowledge;

These specifications require the extended Engineering framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Engineering design requires the Interactive System to perform tasks (the Application) as effectively as desired (Performance). Engineering Research acquires and validates Engineering Knowledge to support Engineering Design Practices.

The Engineering Framework Extension, thus includes: Application; Interactive System; and Performance.

1. Engineering Applications

1.1 Objects

Engineering applications (the tasks, which the interactive system performs) can be described in terms of objects. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, a website application (such as for an academic organisation) can be described for design research purposes in terms of objects; their abstract attributes, supporting the creation of websites; their physical attributes supporting the visual/verbal representation of displayed information on the website pages by means of text and images. Application objects are specified as part of engineering design and can be researched as such.

1.2 Attributes and Levels

The attributes of an engineering application object emerge at different levels of description. For example, characters and their configuration on a webpage are physical attributes of the object ‘webpage’, which emerge at one level. The message on the page is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of an engineering application object are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description. Such relations are specified as part of engineering design.

1.4 Attribute States and Affordance

The attributes of engineering application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a website page (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

An engineering application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The object ‘website’ may be associated within the application as that of site structure (state changes of its organisational attributes) and the authorship (state changes of its textual and image content). In principle, an application may have any level of generality, for example, the writing of personal pages and the writing of academic pages.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing for a special group of users’, may each have a website page as their transform, where the pages are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those pages would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute an additional (unsatisfied) User Requirement and result in a new Interactive System.

1.6 Application Goals

The requirement for the transformation of engineering application objects is expressed in the form of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a website page, making its messages less complex and so more clear, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and images and of associated syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter might constitute part of an engineering design, calling upon engineering knowledge as: design guidelines/models and methods/specific design principles/general design principles.

1.7 Engineering Application as: performing tasks effectively, as desired.

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – website pages with different styles. The concept of ‘performing tasks effectively, as desired’ describes the variance of an actual transform with that specified by a product goal.

1.8 Engineering Application and the User

One description of the application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, users express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘performing tasks effectively, as desired’.

From product goals is derived a structure of related task goals, which can be assigned, by engineering design practice, either to the user or to the interactive computer (or both) within an associated interactive system. Task goals assigned to the user by engineering design are those, intended to motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Engineering Interactive Computers

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a webmaster, using a website application, whose purpose is to construct websites, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The webmaster and the website application may transform the object ‘page’ by changing both the attributes of its meaning and the attributes of its layout, both text and images.

The behaviours of the human and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the human does’, in contrast with ‘what is done’ (i.e. attribute state changes of application objects).

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a webmaster interacting with a website application is a user, whose behaviours include receiving and replying to messages, sent to the website.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours. They are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine, and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a webmaster has the product goal, required to maintain the circulation of a website newsletter to a target audience. The webmaster interacts with the computer by means of the user interface (whose behaviours include the transmission of information in the newsletter). Hence, the webmaster acquires a representation of the current circulation by collating the information displayed by the computer screen and assessing it by comparison with the conditions, specified by the product goal. The webmaster reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour – selecting menu options, for example.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems extert a ‘mutual influence’ or interaction. Their configuration principally determines the interactive system and engineering design and research.

Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a webmaster interact with the behaviours of a website application. The webmaster’s behaviours influence the behaviours of the interactive computer (access the image function), while the behaviours of the interactive computer influence the selection behaviour of the webmaster (among possible image types). The design of their interaction – the webmaster’s selection of the image function, the computer’s presentation of possible image types – determines the interactive system, comprising the webmaster and interactive computer behaviours in their planning and control of webpage creation. The interaction may be the object of engineering design and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of an inappropriate image, required on a page is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the field for the appropriate image as an attribute state change in the spacing of the page. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early image editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the GUI ‘fill-in’ behaviours. Engineering design research would be expected to have contributed to the latter . The assignment of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human Resource Costs

‘Performing tasks effectively, as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated with the user and distinguished as behavioural user costs.

Behavioural user costs are the resource costs, incurred by the user (that is, by the implementation of behaviours) to effect an application. They are both physical and mental. Physical costs are those of physical behaviours, for example, the costs of using the mouse and of attending to a screen display; they may be expressed for engineering design purposes as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed for engineering design purposes as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs.

3. Performance of the Engineering Interactive Computer System and the User.

‘To perform tasks effectively, as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘performing tasks effectively as desired’, that is, performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued. Desired performance is the object of engineering design.

Behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer.

‘Performing tasks effectively as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of engineering design and so of design research.

The common measures of human ‘performance’ – errors and time, are related in this notion of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Following the Engineering Design Research exemplar diagram, researchers need to specify:

User Requirements (unsatisfied) and Interactive System;
Design Problem and Design Solution for design guidelines/models and methods Engineering Knowledge;
Specific Principle Design Problem and Specific Principle Design Solution for Specific Substantive and Methodological Principle Engineering Knowledge;
General Principle Design Problem and General Principle Design Solution for General Substantive and Methodological Principle Engineering Knowledge;

These specifications require the extended Engineering framework to include: the Application; the Interactive System; and Performance, relating the former to the latter. Engineering design requires the Interactive System to perform task effectively (the Application) as desired (Performance). Engineering Research acquires and validates Engineering Knowledge to support Engineering Design Practice.

TheEngineering Framework Extension, thus includes: Application; Interactive System; and Performance.

1 Engineering Applications

1.1 Objects

Engineering applications (the ‘tasks’ the interactive system ‘performs effectively’) can be described as objects. Such applications occur in the need of organisations for interactive systems. Objects may be both abstract and physical and are characterised by their attributes. Abstract attributes are those of information and knowledge. Physical attributes are those of energy and matter.

For example, a website application (such as for an academic organisation) can be described for design research purposes in terms of objects; their abstract attributes, supporting the creation of websites; their physical attributes supporting the visual/verbal representation of displayed information on the website pages by means of text and images. Application objects are specified as part of engineering design and can be researched as such.

1.2 Attributes and Levels

The attributes of an engineering application object emerge at different levels of description. For example, characters and their configuration on a webpage are physical attributes of the object ‘webpage’, which emerge at one level. The message on the page is an abstract attribute, which emerges at a higher level of description.

1.3 Relations between Attributes

Attributes of engineering application objects are related in two ways. First, attributes are related at different levels of complexity. Second, attributes are related within levels of description.

1.4 Attribute States and Affordance

The attributes of engineering application objects can be described as having states. Further, those states may change. For example, the content and characters (attributes) of a website page (object) may change state: the content with respect to meaning and grammar; its characters with respect to size and font. Objects exhibit an affordance for transformation, associated with their attributes’ potential for state change.

1.5 Applications and the Requirement for Attribute State Changes

An engineering application may be described in terms of affordances. Accordingly, an object may be associated with a number of applications. The object ‘website’ may be associated within the application as that of site structure (state changes of its organisational attributes) and the authorship (state changes of its textual and image content). In principle, an application may have any level of generality, for example, the writing of personal pages and the writing of academic pages.

Organisations have applications and require the realisation of the affordance of their associated objects. For example, ‘completing a survey’ and ‘writing for a special group of users’, may each have a website page as their transform, where the pages are objects, whose attributes (their content, format and status, for example) have an intended state. Further editing of those pages would produce additional state changes, and therein, new transforms. Requiring new affordances might constitute an additional (unsatisfied) User Requirement and result in a new Interactive System.

1.6 Application Goals

Organisations express the requirement for the transformation of engineering application objects in terms of goals. A product goal specifies a required transform – the realisation of the affordance of an object. A product goal generally supposes necessary state changes of many attributes. The requirement of each attribute state change can be expressed as an application task goal, derived from the product goal.

So, for example, the product goal demanding transformation of a website page, making its messages less complex and so more clear, would be expressed by task goals, possibly requiring state changes of semantic attributes of the propositional structure of the text and images and of associated syntactic attributes of the grammatical structure. Hence, a product goal can be re-expressed as an application task goal structure, a hierarchical structure expressing the relations between task goals, for example, their sequences. The latter might constitute part of an engineering design, calling upon engineering knowledge as: design guidelines/models and methods/specific design principles/general design principles.

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy the same product goal – e-mails with different styles, for example, where different transforms exhibit different compromises between attribute state changes of the application object. There may also be transforms, which fail to meet the product goal. The concept of ‘performing tasks effectively as desired’ describes the variance of an actual transform with that specified by a product goal. It enables all possible outcomes of an application to be equated and evaluated. Such transforms may become the object of engineering design and so research.

1.7 Engineering Application as: performing tasks effectively, as desired.

The transformation of an object, associated with a product goal, involves many attribute state changes – both within and across levels of complexity. Consequently, there may be alternative transforms, which satisfy a product goal – website pages with different styles. The concept of ‘performing tasks effectively, as desired’ describes the variance of an actual transform with that specified by a product goal.

.

1.8 Engineering Application and the User

Description of the engineering application then, is of objects, characterised by their attributes, and exhibiting an affordance, arising from the potential changes of state of those attributes. By specifying product goals, organisations express their requirement for transforms – objects with specific attribute states. Transforms are produced by ‘performing tasks effectively, as desired’, which occurs only by means of objects, affording transformation and interactive systems, capable of producing a transformation. Such production may be (part of) a engineering design.

From product goals is derived a structure of related task goals, which can be assigned either to the user or to the interactive computer (or both) within the design of an associated interactive system. The task goals assigned to the user are those, which motivate the user’s behaviours. The actual state changes (and therein transforms), which those behaviours produce, may or may not be those specified by task and product goals, a difference expressed by the concept ‘as desired’, characterised in terms of: wanted/needed/experienced/felt/valued.

2.Engineering Interactive Computers and the Human

2.1 Interactive Systems

An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all human and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a webmaster, using a website application, whose purpose is to construct websites, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of the interactive system can be established and so designed and researched.

Users are able to conceptualise goals and their corresponding behaviours are said to be intentional (or purposeful). Interactive computers are designed to achieve goals and their corresponding behaviours are said to be intended (or purposive). An interactive system can be described as a behavioural system, distinguished by a boundary enclosing all user and interactive computer behaviours, whose purpose is to achieve and satisfy a common goal. For example, the behaviours of a website secretary and a web application, whose purpose is to manage the site, constitute an interactive system. Critically, it is only by identifying the common goal, that the boundary of an interactive system can be established and so designed and researched.

Interactive systems transform objects by producing state changes in the abstract and physical attributes of those objects (see 1.1). The webmaster and the website application may transform the object ‘page’ by changing both the attributes of its meaning and the attributes of its layout, both text and images.

The behaviours of the user and the interactive computer are described as behavioural sub-systems of the interactive system – sub-systems, which interact. The human behavioural sub-system is more specifically termed the user. Behaviour may be loosely understood as ‘what the user does’, in contrast with ‘what is done’ (that is, attribute state changes of application objects). More precisely the user is described as:

a system of distinct and related user behaviours, identifiable as the sequence of states of a user interacting with a computer to perform tasks effectively, as desired and corresponding with a purposeful (intentional) transformation of application objects.

Although expressible at many levels of description, the user must at least be described at a level, commensurate with the level of description of the transformation of application objects. For example, a webmaster interacting with a website application is a user, whose behaviours include receiving and replying to messages, sent to the website.

2.2 Humans as a System of Mental and Physical Behaviours

The behaviours, constituting an interactive system, are both physical and abstract. Abstract behaviours are generally the acquisition, storage, and transformation of information. They represent and process information, at least concerning: application objects and their attributes, attribute relations and attribute states and the transformations, required by goals. Physical behaviours are related to, and express, abstract behaviours.

Accordingly, the user is described as a system of both mental (abstract) and overt (physical) behaviours, which extend a mutual influence – they are related. In particular, they are related within an assumed hierarchy of behaviour types (and their control), wherein mental behaviours generally determine and are expressed by, overt behaviours. Mental behaviours may transform (abstract) application objects, represented in cognition or express, through overt behaviour, plans for transforming application objects.

For example, a webmaster has the product goal, required to maintain the circulation of a website newsletter to a target audience. The webmaster interacts with the computer by means of the user interface (whose behaviours include the transmission of information in the newsletter). Hence, the webmaster acquires a representation of the current circulation by collating the information displayed by the computer screen and assessing it by comparison with the conditions, specified by the product goal. The webmaster reasons about the attribute state changes, necessary to eliminate any discrepancy between current and desired conditions of the process, that is, the set of related changes, which will produce and circulate the newsletter, ‘as desired’. That decision is expressed in the set of instructions issued to the interactive computer through overt behaviour – selecting menu options, for example.

The user is described as having cognitive, conative and affective aspects. The cognitive aspects are those of knowing, reasoning and remembering; the conative aspects are those of acting, trying and persevering; and the affective aspects are those of being patient, caring and assuring. Both mental and overt user behaviours are described as having these three aspects, all of which may contribute to ‘performing tasks effectively, as desired as wanted/needed/experienced/felt/valued.

2.3 Human-Computer Interaction

Although user and interactive computer behaviours may be described as separable sub-systems of the interactive system, these sub-systems exert a ‘mutual influence’, that is to say they interact. Their configuration principally determines the interactive system and so its design and the associated research into that and other possible engineering designs.

Interaction of the user and the interactive computer behaviours is the fundamental determinant of the interactive system, rather than their individual behaviours per se. Interaction is described as: the mutual influence of the user (i.e. behaviours) and the interactive computer (i.e behaviours), associated within an interactive system. For example, the behaviours of a webmaster interact with the behaviours of a website application. The webmaster’s behaviours influence the behaviours of the interactive computer (access the image function), while the behaviours of the interactive computer influence the selection behaviour of the webmaster (among possible image types). The design of their interaction – the webmaster’s selection of the image function, the computer’s presentation of possible image types – determines the interactive system, comprising the webmaster and interactive computer behaviours in their planning and control of webpage creation. The interaction may be the object of engineering design and so design research.

The assignment of task goals by design then, to either the user or the interactive computer, delimits the former and therein specifies the design of the interaction. For example, replacement of an inappropriate image, required on a page is a product goal, which can be expressed as a task goal structure of necessary and related attribute state changes. In particular, the field for the appropriate image as an attribute state change in the spacing of the page. Specifying that state change may be a task goal assigned to the user, as in interaction with the behaviours of early image editor designs or it may be a task goal assigned to the interactive computer, as in interaction with the GUI ‘fill-in’ behaviours. Engineering design research would be expected to have contributed to the latter . The assignment of the task goal of specification constitutes the design of the interaction of the user and interactive computer behaviours in each case, which in turn may become the object of research.

2.4 Human On-line and Off-line Behaviours

User behaviours may comprise both on-line and off-line behaviours: on-line behaviours are associated with the interactive computer’s representation of the application; off-line behaviours are associated with non-computer representations of the application.

As an illustration of the distinction, consider the example of an interactive system, consisting of the behaviours of a website secretary and an e-mail application. They are required to produce a paper-based copy of a dictated letter, stored on audio tape. The product goal of the interactive system here requires the transformation of the physical representation of the letter from one medium to another, that is, from tape to paper. From the product goal derives the task goals, relating to required attribute state changes of the letter. Certain of those task goals will be assigned to the secretary. The secretary’s off-line behaviours include listening to and assimilating the dictated letter, so acquiring a representation of the application object. By contrast, the secretary’s on-line behaviours include specifying the represention by the interactive computer of the transposed content of the letter in a desired visual/verbal format of stored physical symbols.

On-line and off-line user behaviours are a particular case of the ‘internal’ interactions between a user’s behaviours as, for example, when the web secretary’s keying interacts with memorisations of successive segments of the dictated letter.

2.5 Structures and the Human

Description of the user as a system of behaviours needs to be extended, for the purposes of design and design research, to the structures supporting that behaviour.

Whereas user behaviours may be loosely understood as ‘what the human does’, the structures supporting them can be understood as ‘the support for the human to be able to do what they do’. There is a one-to-many mapping between a user’s structures and the behaviours they might support: thus, the same structures may support many different behaviours.

In co-extensively enabling behaviours at each level of description, structures must exist at commensurate levels. The user structural architecture is both physical and mental, providing the capability for a user’s overt and mental behaviours. It provides a represention of application information as symbols (physical and abstract) and concepts, and the processes available for the transformation of those representations. It provides an abstract structure for expressing information as mental behaviour. It provides a physical structure for expressing information as physical behaviour.

Physical user structure is neural, bio-mechanical and physiological. Mental structure consists of representational schemes and processes. Corresponding with the behaviours it supports and enables, user structure has cognitive, conative and affective aspects. The cognitive aspects of user structures include information and knowledge – that is, symbolic and conceptual representations – of the application, of the interactive computer and of the user themselves, and it includes the ability to reason. The conative aspects of user structures motivate the implementation of behaviour and its perseverence in pursuing task goals. The affective aspects of user structures include the personality and temperament, which respond to and support behaviour. All three aspects may contribute to ‘ performing tasks effectively, as desired as wanted/needed/experienced/felt/valued’.

To illustrate this description of mental structure, consider the example of the structures supporting a web user’s behaviours. Physical structure supports perception of the web page display and executing actions to the web application. Mental structures support the acquisition, memorisation and transformation of information about how the web application is conducted. The knowledge, which the web user has of the application and of the interactive computer, supports the collation, assessment and reasoning about the actions required.

The limits of user structures determine the limits of the behaviours they might support. Such structural limits include those of: intellectual ability; knowledge of the application and the interactive computer; memory and attentional capacities; patience; perseverence; dexterity; and visual acuity etc. The structural limits on behaviour may become particularly apparent, when one part of the structure (a channel capacity, perhaps) is required to support concurrent behaviours, perhaps simultaneous visual attending and reasoning behaviours. The user then, is ‘resource-limited’ by the co-extensive user structures.

The behavioural limits of the user, determined by structure, are not only difficult to define with any kind of completeness, they may also be variable, because that structure may change, and in a number of ways. A user may have self-determined changes in response to the application – as expressed in learning phenomena, acquiring new knowledge of the application, of the interactive computer, and indeed of themselves, to better support behaviour. Also, user structures degrade with the expenditure of resources by behaviour, as demonstrated by the phenomena of mental and physical fatigue. User structures may also change in response to motivating or de-motivating influences of the organisation, which maintains the interactive system.

It must be emphasised that the structure supporting the user is independent of the structure supporting the interactive computer behaviours. Neither structure can make any incursion into the other and neither can directly support the behaviours of the other. (Indeed this separability of structures is a pre-condition for expressing the interactive system as two interacting behavioural sub-systems). Although the structures may change in response to each other, they are not, unlike the behaviours they support, interactive; they are not included within the interactive system. The combination of structures of both user and interactive computer, supporting their interacting behaviours is described as the user interface .

2.6 Human Resource Costs

‘Performing tasks effectively as desired’ by means of an interactive system always incurs resource costs. Given the separability of the user and the interactive computer behaviours, certain resource costs are associated directly with the user and distinguished as structural user costs and behavioural user costs.

Structural user costs are the costs of the user structures. Such costs are incurred in developing and maintaining user skills and knowledge. More specifically, structural user costs are incurred in training and educating users, so developing in them the structures, which will enable the behaviours necessary for an application . Training and educating may augment or modify existing structures, provide the user with entirely novel structures, or perhaps even reduce existing structures. Structural user costs will be incurred in each case and will frequently be borne by the organisation. An example of structural user costs might be the costs of training a secretary to use a GUI web interface in the particular style of layout, required for an organisation’s correspondence with its clients and in the operation of the interactive computer by which that layout style can be created.

Structural user costs may be differentiated as cognitive, conative and affective structural costs. Cognitive structural costs express the costs of developing the knowledge and reasoning abilities of users and their ability for formulating and expressing novel plans in their overt behaviour – as necessary for ‘performing tasks effectively, as desired’. Conative structural costs express the costs of developing the activity, stamina and persistence of users as necessary for an application. Affective structural costs express the costs of developing in users their patience, care and assurance as necessary for an application.

Behavioural user costs are the resource costs, incurred by the user (i.e by the implementation of their of behaviours) in recruiting user structures to effect an application. They are both physical and mental resource costs. Physical behavioural costs are the costs of physical behaviours, for example, the costs of making keystrokes on a keyboard and of attending to a web screen display; they may be expressed without differentiation as physical workload. Mental behavioural costs are the costs of mental behaviours, for example, the costs of knowing, reasoning, and deciding; they may be expressed without differentiation as mental workload. Mental behavioural costs are ultimately manifest as physical behavioural costs. Costs are an important aspect of the engineering design of an interactive computer system.

When differentiated, mental and physical behavioural costs are described as the cognitive, conative and affective behavioural costs of the user. Cognitive behavioural costs relate to both the mental representing and processing of information and the demands made on the user’s extant knowledge, as well as the physical expression thereof in the formulation and expression of a novel plan. Conative behavioural costs relate to the repeated mental and physical actions and effort, required by the formulation and expression of the novel plan. Affective behavioural costs relate to the emotional aspects of the mental and physical behaviours, required in the formulation and expression of the novel plan. Behavioural user costs are evidenced in user fatigue, stress and frustration; they are costs borne directly by the user and so need to be taken into account in the engineering design process.

3. Performance of the Engineering Interactive Computer System and the User.

‘To perform tasks effectively, as desired’ derives from the relationship of an interactive system with its application. It assimilates both how well the application is performed by the interactive system and the costs incurred by it. These are the primary constituents of ‘performing tasks effectively, as desired’, that is performance. They can be further differentiated, for example, as wanted/needed/experienced/felt/valued.

A concordance is assumed between the behaviours of an interactive system and its performance: behaviours determine performance. How well an application is performed by an interactive system is described as the actual transformation of application objects with regard to the transformation, demanded by product goals. The costs of carrying out an application are described as the resource costs, incurred by the interactive system and are separately attributed to the user and the interactive computer. Specifically, the resource costs incurred by the user are differentiated as: structural user costs – the costs of establishing and maintaining the structures supporting behaviour; and behavioural user costs – the costs of the behaviour, recruiting structure to its own support. Structural and behavioural user costs are further differentiated as cognitive, conative and affective costs. Design requires attention to all types of resource costs – both those of the user and of the interactive computer.

‘Performing tasks effectively, as desired’ by means of an interactive system may be described as absolute or as relative, as in a comparison to be matched or improved upon. Accordingly, criteria expressing ‘as desired’ may either specify categorical gross resource costs and how well an application is performed or they may specify critical instances of those factors to be matched or improved upon. They are the object of engineering design and so of design research.

Discriminating the user’s performance within the performance of the interactive system would require the separate assimilation of user resource costs and their achievement of desired attribute state changes, demanded by their assigned task goals. Further assertions concerning the user arise from the description of interactive system performance. First, the description of performance is able to distinguish the goodness of the transforms from the resource costs of the interactive system, which produce them. This distinction is essential for engineering design, as two interactive systems might be capable of producing the same transform, yet if one were to incur a greater resource cost than the other, it would be the lesser (in terms of performance) of the two systems.

Second, given the concordance of behaviour with ‘performing tasks effectively, as desired’, optimal user (and equally, interactive computer) behaviours may be described as those, which incur a (desired) minimum of resource costs in producing a given transform. engineering design of optimal user behaviour would minimise the resource costs, incurred in producing a transform of a given goodness. However, that optimality may only be categorically determined with regard to interactive system performance and the best performance of an interactive system may still be at variance with what is desired of it. To be more specific, it is not sufficient for user behaviours simply to be error-free. Although the elimination of errorful user behaviours may contribute to the best application possible of a given interactive system, that performance may still be less than ‘as desired’. Conversely, although user behaviours may be errorful, an interactive system may still support ‘performing tasks effectively, as desired’.

Third, the common measures of human ‘performance’ – errors and time, are related in this conceptualisation of performance. Errors are behaviours, which increase resource costs, incurred in producing a given transform or which reduce the goodness of the transform or both. The duration of user behaviours may (very generally) be associated with increases in behavioural user costs.

Fourth, structural and behavioural user costs may be traded-off in the design of an application. More sophisticated user structures, supporting user behaviours, that is, the knowledge and skills of experienced and trained users, will incur high (structural) costs to develop, but enable more efficient behaviours – and therein, reduced behavioural costs.

Fifth, resource costs, incurred by the user and the interactive computer may be traded-off in the design of the performance of an application. A user can sustain a level of performance of the interactive system by optimising behaviours to compensate for the poorly designed behaviours of the interactive computer (and vice versa), that is, behavioural costs of the user and interactive computer are traded-off in the design process. This is of particular importance as the ability of users to adapt their behaviours to compensate for the poor design of interactive computer-based systems often obscures the fact that the systems are poorly designed.

Requirement 1: The framework (as a basic support structure) is for a discipline (as an academic field of study and branch of knowledge).

Newman is concerned with the discipline of Software Engineering (Comment 1), of which HCI is treated as being a part (Comment 3). Software Engineering, in turn, is considered to be an Engineering Design Discipline and so by implication an academic field of study and a branch of knowledge.

Requirement 2: The framework is for HCI (as human-computer interaction) as engineering (as design for performance).

The paper references performance, expressed both as errors (Comment 11) and time (Comment 12)

Requirement 3: The framework has a general problem (as engineering design) with a particular scope (as human computer interactions to perform tasks effectively, as desired).

The paper espouses the concept of HCI as engineering design (Comment 3). Tasks, such as text editing, are performed as needed and required by the end-user. Such performance is expressed in terms of time (Comment 11) and time (Comment 12).

Requirement 4:  Research ( as acquisition and validation) acquires (as study and practice) and validates (as confirms) knowledge (as design guidelines/models and methods/principles – specific/ general and declarative/methodological).

The paper references the designed artefact (Comment 5) and the methods used to design it (Comments 2 and 4). This knowledge comprises empirical methods, such as testing (Comment 7) and also analytic models (Comment 9). A model is proposed linking needs to their implementation (Comment 6).

Requirement 5:  This knowledge supports (facilitates) practices (diagnose design problem and prescribe design solution), which solve (as resolve) the general design problem of engineering design.

The paper references design practices, such as implement and test (Comment 7), generate and test (Comment 6) and both analytical and empirical practices (Comments 8 and 9).

Conclusion:

Newman’s paper obviously espouses the concept of HCI, as part of Software Engineering, and so part of an engineering design discipline. The framework is more-or-less complete at a high level of description with its references to models, methods and performance. Its needs/implementation model (Figure 1) is not operationalised, however, and so the paper does not provide a case-study of the acquisition of design knowledge. To do so would require the framework to be expressed at lower levels of description, as proposed here.

Discipline

Innovation – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Art – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Craft – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Applied – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Science – Discipline: an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

Engineering – an academic field of study/branch of knowledge (academic – scholarly; field of study – subject area; branch of knowledge – division of information/learning).

HCI

Innovation – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Art – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Craft – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Applied – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Science – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Engineering – human-computer interaction (human – individual/group; computer – interactive/embedded; interaction – active/passive).

Framework Type

Innovation – Innovation: novel (novel – new ideas/methods/devices etc)

Art – Art: creative expression corresponding to some ideal or criteria (creative – imaginative, inventive); (expressive – showing by taking some form); ideal – visionary/perfect); criterion – standard).

Craft – Craft: best practice design (practice – design/evaluation; design – specification/implementation).

Applied – Applied: application of other discipline knowledge (application – addition to/prescription; discipline – academic field/branch of knowledge; knowledge – information/learning).

Science – understanding (explanation/prediction)

Engineering – design for performance (design – specification/implementation; performance – how well effected).

General Problem

Innovation – innovation design (innovation – novelty; design – specification/implementation).

Art – art design (art – ideal creative expression; design – specification/implementation).

Craft – craft design (craft – best practice; design – specification/implementation).

Applied – applied design (applied – added/prescribed; design – specification/implementation).

Science – understanding human-computer interactions (understand – explanation/prediction; human – individual/group; computer – interactive/embedded; interaction – active/passive)

Engineering – engineering design (engineering – design for performance; design – specification/implementation).

Particular Scope

Innovation – innovative human-computer interactions to do something as desired (innovative – novel; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued).

Art – art human-computer interactions to do something as desired (art – creation/expression; human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task); desired: wanted/needed/experienced/felt/valued).

Craft – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Applied – human-computer interactions to do something as desired, which satisfy user requirements in the form of an interactive system (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued; user – human; requirements – needs; satisfied – met/addressed; interactive – active/passive; system – user-computer).

Science – human-computer interactions to do something as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; something – action/task; desired: wanted/needed/experienced/felt/valued.

Engineering – human-computer interactions to perform tasks effectively as desired (human – individual/group; computer – interactive/embedded; interactions – active/passive; perform – effect/carry out; tasks – actions; desired – wanted/needed/experienced/felt/valued).

Research

Innovation – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – patents/expert advice/experience/examples).

Art – acquires and validates knowledge (acquires – creates by study/practice; validates – confirms; knowledge – experience/expert advice/other artefacts.

Craft – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Science – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools; practices – explanation/prediction).

Engineering – acquires and validates knowledge to support practices (acquires – creates; validates – confirms; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Knowledge

Innovation – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Art – supports practices (supports – facilitates/makes possible; practices – trial and error/implement and test).

Craft – supports practices (supports – facilitates/makes possible; practices – trial-and-error/implement and test).

Applied – supports practices (supports – facilitates/makes possible; practices – trial-and-error/apply and test).

Science – supports practices (supports – facilitates/makes possible; practices – explanation/prediction).

Engineering – supports practices (supports – facilitates/makes possible; practices – diagnose design problems/prescribe design solutions).

Practices

Innovation – supported by knowledge (supported – facilitated; knowledge – patents/expert advice/experience/examples).

Art – supported by knowledge (supported – facilitated/made possible; knowledge – experience/expert advice/other artefacts).

Craft – supported by knowledge (supported – facilitated; knowledge – heuristics/methods/expert advice/successful designs/case-studies).

Applied – supported by knowledge (supported – facilitated; knowledge – guidelines; heuristics/methods/expert advice/successful designs/case-studies).

Science – supported by knowledge (supported – facilitated; knowledge – theories/models/laws/data/hypotheses/analytical and empirical methods and tools ).

Engineering – supported by knowledge (supported – facilitated; knowledge – design guidelines/models and methods/principles – specific/ general and declarative/methodological).

Solution

Innovation – resolution of a problem (resolution – answer/address; problem – question/doubt).

Art – resolution of the general problem (resolution – answer/address; problem – question/doubt).

Craft – resolution of a problem (resolution – answer/address; problem – question/doubt).

Applied – resolution of a problem (resolution – answer/address; problem – question/doubt).

Science – resolution of a problem (resolution – answer/address; problem – question/doubt).

Engineering – resolution of a problem (resolution – answer/address; problem – question/doubt).

The ‘aesthetics of art’ here can be thought of as an ideal creative expression, especially if the notion is decomposed further.

(Experience) design and user/audience understanding can both be considered as general problems of art.

Pleasure, play and long term engagement here can all be considered to be part of the scope of art human-computer interactions as to do something as desired. What would be desired here is an acceptable level of pleasure, play and long-term engagement or some such.

Design process here is obviously HCI practice, as supported by research. Evaluation and the associated methods constitute HCI knowledge.

The claim here is an interesting one – that HCI can contribute to the art-making process, as well as, for example, helping to design art-supporting applications.

Here research results constitute HCI knowledge, which support HCI art practice experiences. The ‘expanding area’ appears to be HCI in general, rather than any particular form of HCI field or discipline.

The ‘critical language’ referenced here might be taken to include the kind of frameworks proposed on this website. Other types of language would be, of course, included. Further details would be needed to judge the matter.

See also Comment 5.

See also Comments 5 and 8.

See also Comment 3.

See also Comment 3.

The framework obviously offers a range of lower-level descriptions of interactive artworks. These can be constructively compared with the extended lower-level frameworks proposed here. The comparison can check for overlap and differences and be mutually beneficial.

See also Comment 2.

See also Comment 4, concerning the importance of research and its practices, such as evaluation.

‘Development’ and ‘Evaluation’ here constitute a high-level description of design and so design practice. Design knowledge acquired by research would be expected to support such practices. Costello’s (2007) ‘pleasure framework’, if claimed as design knowledge, would be an example as such.

Note that evaluation methods can support both design as well as understanding, as claimed here. See also Comments  2 and 4.

Note that HCI research, then,  can acquire acquire knowledge to support both art application and art creation processes. See also Comment 5.

It is unclear whether this set of phases is primarily (or indeed only) descriptive or whether they are a form of knowledge to support the practice of design, understanding or both. See also Comments 2 and 4 and more generally those associated with the Costello Pleasure framework.

Note that the Engagement and Pleasure Frameworks, either together or separately, can be considered as part of a lower-level description of an ‘understanding’ or ‘design’ discipline or field of study framework. So also, of course, could be the Experience/Engagement relationship. See Comments 2 and 3.

This paper obviously contributes to providing a framework ‘which informs creative practice in the area’ of interactive art. The framework, then is a form of knowledge, which supports HCI practice. See also Comments 2 and 3.

See Comment 20.

The transfer of research to development communities here constitutes the very idea of Applied Psychology.

The primary applied science in the case of HCI is Psychology, although this does not exclude others, for example, Sociology, Ethnomethodology etc.

These examples contain lower-level descriptions of applied frameworks for HCI, some woth and some without overlaps.

The application of empirical methodologies and the data of Applied Psychology have also contributed to the development of HCI research and practice.

This relationship is the nub of Application Framework Illustration presented in this paper.

Applicable Cognitive Theory here is the basic science and Software Engineering the object of its application. See also Comments 2 and 4.

Basic (Psychology) research and artifact (interactive system) design and their relationship is of the primary concern here.

The need to facilitate the applicability and impact of basic cognitive theory on artifact design suggests its current applicability is unacceptable.

Long’s framework is itself an applied framework.

Lower-level descriptions of the Applied Framework are to be found in the different representations referenced here.

Note that the operationalisation of basic Psychology theory for the purposes of design is not the same as the operational discovery representation of that theory.

Note that the scope of the science base and the scope of the applied base can be the same, although the purposes (and so the knowledge) differ.

Note that the (Psychology) science base in the form of Cognitive Theory seeks both understanding of human-computer interaction design issues (presumably as explanation of known phenomena and the prediction of unknown phenomena) and the resolution of design problems.

Hence the requirement for both a science and an applied framework for HCI. The former seeks to understand the phenomena, associated with humans interacting with computers,while the later seeks to support the design of human-computer interactions.

Note that the validation of basic psychological theory does not of itself guarantee its successful resolution of design problems. See also Comment 14.

Hence the need here for separate frameworks for both Innovation (as invention) and Craft. See the relevant framework sections.

See Comment 15.

See also Comments 15 and 17.

The behaviours required to undertake and to complete such tasks as desired would need to be included at lower levels of any  applied framework.

See also Comments 15, 17 and 18.

A cognitive engineering paradigm would not have the same discipline general problem as a cognitive scientific paradigm – the former would be understanding and the latter design. In addition, both would have its own different knowledge in the form of models and methods and practices (the former the diagnosis of design problems of humans interacting with computers and the prescription of their associated design solutions, the latter the explanation and prediction of phenomena, associated with humans interacting with computers.

Any applied framework must ultimately include levels of description, which capture the behaviours performed in complex tasks and associated with the action decomposition and knowledge requirements, referenced here.

The notion of ‘sufficiency filter’ is an interesting one. However, ultimately it needs to be integrated with other concepts, supporting  the notion of validation – conceptualisation; operationalisation; test; and generalisation with respect to understanding or design (or both). See also Comment 15.

Prediction and scope, at the end of the day, cannot be separated. Prediction cannot be tsted in the absence of a stated scope.

To be known as appropriate to the domain, the latter needs to be explicitly included in the theory.

What matters in an applied context is, more generally, how well a task is performed. That may, or may not, be reflected by errors, persistent or not.

‘Quick and dirty methodology’ and ‘tar pit’ avoidance need to be integrated with notions of validation, such as – conceptualisation; operationalisation; test; and generalisation. See also Comments 15 and 23.

Barnard’s point is well taken here. However, the ‘more applicable theoretical ideas have still to be validated with respect to design. See also Comments 15, 17 and 27.

This cycle is the basis and justification for the inclusion of Barnard’s paper as an applied framework.

See Comments 19 and 22, concerning the framework requirements for the low levels of the description of humans interacting with computers involved in their design.

Cognitive theory, here, is part of the discipline of Psychology, which in turn sees itself as a Science Discipline.

Understanding, here, in the manner of science is taken to mean the explanation and prediction of phenomena.

What the science of Psychology base has to gain, here, is taken to be the phenomena associated with humans interacting with computers (Comment 2).

Behavioural requirements, here, comprise the human-computer interaction phenomena, which the science of Psychology seeks to understand by means of Cognitive Theory.

See Comment 4.

See Comments 2 and 4.

Task goals imply the requirement for lower-level descriptions of the human-computer interactions, which constitute the phenomena to be understood by the science base of Psychology, as expressed in Cognitive Theory.

Research, here, refers to the acquisition of Cognitive Theory as scientific knowledge, whose parent discipline is Psychology.

Verification , here, is taken to include validation, which in turn comprises: conceptualisation; operationalisation; test; and generalisation.

Applied frameworks, as referenced here, are clearly different from; but dependent on, science/Psychology/Cognitive Theory frameworks.

Knowledge and theory in the science basis seeks to understand the phenomena, associated with humans interacting with computers. Cognitive Theory, then, requires frameworks at the detailed level of those interactions. See also Comment 7.

Cognitive Science and Cognitive Engineering Paradigms are clearly distinguished here. This distinction is consistent with the position taken by Frameworks for HCI on this site.

Software engineering here, as it includes User Requirements as part of its scope, is to be assumed to include HCI and certainly for the purposes in hand.

Methods here constitute (HCI) design knowledge and support (HCI) design practice. See also Comments 8 and 9.

Software engineering here (and so HCI,as viewed by some researchers) is considered to be an engineering design discipline.

See Comment 2.

The designed artefact here is the product of design knowledge, such as methods, supporting design practice. (See also Comments 2, 4, 8, 9, and 10).

Further details are provided here concerning the general nature of design and its different aspects. Testing is obviously an important one. See also Comments 7 and 8.

Empirical testing is a critical component of the HCI contribution to design and comprises a host of different methods. See also Comments 2, 4 and 8.

Implement and test are two of the most important HCI design processes. See also Comments 2, 4, and 7.

Analytical and empirical are the two major classes of HCI design methods and so practices. Analytical models, as here, would constitute HCI declarative (or substantive) knowledge (as opposed to methodological knowledge – see Comments 2, 4, 6, and 8.

Iteration of implementation and test methods constitutes part of the majority of HCI design practices and so design cycles. See also Comment 2, 4, 6, and 8.

Errors, as here, along with time, are primary criteria for interactive system performance and its testing.

See also Comment 10, concerning errors and time.