C a r r y F o r w a r d in the Development of Mi li t ar y Pl an ni ng Systems
M a r t i n C o l b e r t
U n iv e rs ity C ollege L o n d o n
1 9 9 4
ProQuest Number: 10017240
All rights reserved
INFORMATION TO ALL USERS
The quality of this reproduction is dependent upon the quality of the copy submitted.
In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed,
a note will indicate the deletion.
uest.
ProQuest 10017240
Published by ProQuest LLC(2016). Copyright of the Dissertation is held by the Author.
All rights reserved.
This work is protected against unauthorized copying under Title 17, United States Code. Microform Edition © ProQuest LLC.
ProQuest LLC
789 East Eisenhower Parkway P.O. Box 1346
A c k n o w l e d g e m e n t
special mention: John Long (supervisor)
m e n tio n : all my colleagues at Ergonomics & HCI Unit;
Chris Young and Chris Madams (colleagues at DRA P o rts d o w n );
Carol Gaye, DRA, and Brian Drabble, AIAI (dem onstration and discussion of actual p lan n in g system s);
A b s t r a c t
In recent years, a num ber of difficulties in designing interactions between m ilitary personnel and their command and control (C ^) systems have been identified. These difficulties are persistent and have been attributed to a lack of carry forw ard betw een procurem ent projects.
In response to these difficulties, this thesis attempts to realise and then illustrate carry forw ard in a manner that is characteristic of a particular form of the discipline of Human Computer Interaction (HCI) - inform al HCI Engineering, In essence, inform al HCI Engineering is different from current best practice in that design work addresses general classes of design Problem and instances o f general classes of design Problem, rather than ju st problem instances which are related to other instances in some, unspecified way. C onsequently, in principle, inform al E ngineering offers a d d i t i o n a l opportunities to develop and apply knowledge to design work. S pecifically, it offers additional opportunities to support: (i) the abstraction of general requirem ents from instance requirem ents; (ii) the production o f general specifications in response to general requirem ents; and (iii) the instan tiatio n of general specifications for particular instances. Further, the knowledge applied in support of design may concern c la s s e s of design Problem , rather than ju st instances or a poorly specified range of
instances. In addition, inform al Engineering provides an a d d i t i o n a l way of reasoning about the com pleteness and/or selectivity w ith which design Problem instances are addressed - reasoning with respect to a relevant c la s s .
Two attempts are made to realise carry forward in the desired manner, first, in late evaluation, and second, in specification. Of these, the second attem pt is judged to be more satisfying than the first, since: (i) carry forward is fully carried through; (ii) both a general requirem ent and a general specification are developed; and (iii) in the case reported, the value of the specifications produced are judged likely to outweigh the costs of their d e v e lo p m e n t.
C o n t e n t s
Acknowledgement ... 2
Abstract ... 3
Contents ... 5
Figures ... 10
Tables ... 13
C h a p te r 1. F o rm s o f H C I a n d th e Z e ro —>B uiId S tra te g y S um m ary... 14
1.1. Different Forms o f the Discipline o f Human-Computer Interaction 20 1.1.1 Difficulties in Designing C2 Systems ... 20
1.1.2. Carry Forward and HCI as a Discipline ... 20
1.1.3. The Precise, Technical View of Carry Forward ... 22
1.1.4. C rafting and Engineering H um an-C om puter Interactions for C2 ... 30
1.1.4.1. Immature (Implicit) Craft ... 32
1.1.4.2. Mature (Explicit) Craft ... 38
1.1.4.3. Immature (Informal) Engineering ... 44
1.1.4.4. M ature (Formal) Engineering ... 47
1.2. Zero-->Building a Manner o f Carry Forward: Informal Engineering Now! ... 47
1.2.1. Strategy: Balanced Modelling and Practising with Evaluation ... 47
1.2.2. G enerating a Basic Representation: A bstracting a Prelim inary Conception of the Domain of C2 from the Literature ... 54
1.2.3. Conducting and Reporting Carry Forward Practice: Documenting Illustrative Case Studies ... 60
1.2.4. Assessing the Basic Representations and the Reports of Carry Forward Practice: Comparative Review ... 64
C h a p te r 2. A P re lim in a ry C o n cep tio n of th e D om ain o f M ilita r y C o m m an d a n d C o n tro l
Summary ... 69
2.1. Military C2 as the Planning and Controlling Armed-Conflict ... 73
2.1.1. The Domain of Armed-Conflict ... 75
2.1.1.1. Concepts ... 75
2.1.1.2. Illustration: Accidental Downing of Iran Air Flight 655 on May 3rd, 1988 by U.S.S. Vincennes ... 83
2.1.2. The Domain of Plans for Armed-Conflict ... 88
2.1.2.1. Concepts ... 88
2.1.2.2. Illustration: Planning an H ypothetical Amphibious L an ding... 90
2.2 Assessment o f Face Validity ... 94
2.2.1. Compatibility with Consensus of Domain Experts ... 94
2.2.1.1. Essential and D istinguishing Features of A rm ed-C onflict... 94
2.1.1.2. Essential and D istinguishing Features of Planning Armed-Conflict ... 95
2.2.2. Identity of Points of Reference ... 96
2.2.2.1. Alternative Accounts of Military Incidents ... 97
2.2.2.2. Alternative Views of the Quality of Military Plans ... 98
2.2.2.2.1. Two Types of Military Plan ... 99
2.2.2.2.2. The End-User Views ... 101
2.2.2.2.3. The Pre-Conception-Based Views ... 102
C h a p te r 3. F ir s t A tte m p t: C a r r y F o rw a rd in E v a lu a tio n
Summary ... 105
3.1. Informal Engineering Late Evaluation ... 108
3.1.1. Development of Application Representations ... 108
3.1.1.1. Development of a View of Planning System Effectiveness . 108 3.1.1.1.1. Humans Interacting with Com puters and Performance ... 108
3.1.1.1.2. Planners Interacting with Planning Aids and Planning Performance ... 110
3.1.1.2. Development of a Problem Hierarchy ... 112
3.1.2. Development of an Off-Load Planning W orksystem for University College London ... 113
3.1.3. Use and Increm entation of A pplication R epresentations in Evaluation ... 114
3.1.3.1. Students Interacting with an O ff-Load Planning Worksystem (O PSl) at University College London and Off-Load Planning Perform ance... 116
3.1.3.2. Focus of the Evaluation ... 119
3.1.3.3. Procedure for Obtaining Statements of Performance ... 120
3.1.3.4. Metrics ... 120
3.1.3.5. Instance Requirement: Required Perform ance of O PS l .... 122
3.1.3.6. Instance Specification: Actual Perform ance o f O PSl ... 125
3.1.3.7. The Conformance Between Actual and Required Performance of OPSl ... 126
3.2. Explicit Craft Evaluation ... 129
3.2.1. Application Representations ... 130
3.2.1.1. Other Views of Planning System Effectiveness... 131
3.2.1.2. Views of Effectiveness Generally ... 131
3.2.2. Use and Increm entation of A pplication R epresentations in Evaluation ... 133
3.2.2.1. A View of OPS I s Effectiveness ... 133
3.2.2.2. The Conformance Between Actual and Required Effectiveness of OPSl ... 138
3.3. Assessment o f Case Report ... 138
3.3.1. Scope and Content of Evaluations ... 138
3.3.2. Reasoning About Com pleteness/Selectivity ... 141
3.3.4. Relative Effectiveness of Inform al Engineering Evaluation
f lit ^ _*WüCK*3t#ù
C h a p te r 4. S eco nd A tte m p t: C a r r y F o rw a rd in E v a lu a tio n
Summary ... 150
4.1. Informal Engineering Specification ... 154
4.1.1. Development of Application Representations ... 154
4.1.1.1. Rationale for Selection of Application Representations ... 154
4.1.1.2. Development of a GUI Menu Structure for Work in General and its Associated General Problem Element ... 161
4.1.1.3. Development of a GUI Menu Structure for Planning Tasks and its Associated General Problem Element ... 163
4.1.2. Specification and Implementation of OPSl and SATCONl ... 168
4.1.3. Re-Use and Incrementation of Application Representations in Specification ... 169
4.1.3.1. Specialising a Menu Structure for OPSl ... 177
4.1.3.2. Specialising a Menu Structure for SATCONl ... 180
4.2. Explicit Craft Specification ... 182
4.2.1. Application Representations ... 182
4.2.2. Re-Use and Increm entation of A pplication Representations ... 185
4.3. Assessment o f Case Report ... 189
4.3.1. Scope and Content of Specifications ... 189
4.3.2. Reasoning About Completeness/Selectivity ... 193
4.3.3. Adequacy of Illustration of Informal Engineering ... 195
4.3.4. Relative Effectiveness of Informal Engineering Specification in P ra c tic e ... 195
C h a p te r 5. C lo sin g R e m a rk s 5.1. Response to the Conception Papers ... 198
5.2. Possible Future Work ... 203
5.3. Possible Criticisms o f this Thesis ... 208
F i g u r e s
C h a p t e r 1
Figure l.l(i): The Nature of a Discipline ... 21 Figure l.l(ii): Carry Forward in HCI ... 21 Figure 1.2: Carry Forward as the Development, Re-Use and
Incrementation of Application Representations to
Transform Design Representations ... 24 Figure 1.3: Example 1: Carry Forward in Conventional Applied
S cience... 26 Figure 1.4: Example 2: Carry Forward in Potentially More
Effective Applied S cien ce... 27 Figure 1.5: The HCI Design Cycle ... 28 Figure 1.6: Opportunities to Develop, Re-Use and Increm ent
Application Representations to Transform Design
Representations ... 29 Figure 1.7: D ifferential Effectiveness and Co-existence of D ifferent
Forms of H C I ... 34 Figure 1.8: Carry Forward in Immature (Implicit) HCI Craft ... 35 Figure 1.9: Example of Carry Forward in Mature (Explicit) HCI Craft . 39 Figure 1.10: Carry Forward in Immature (Informal) HCI Engineering 45 Figure 1.11: A Strategy for the Development of HCI as Informal
Engineering: Zero—>Building ... 50 F igure 1.12: C rafting and (Inform ally) E ngineering H um an-Com puter
Interactions: Progressive Evolution ... 54 Figure 1.13: A Conception for Human-Computer Interaction ... 55 Figure 1.14: Domain Conceptions of Different Levels of Generality .... 59 Figure 1.15: A ‘Basic-R epresentation-C entric’ View of a Strategy for
the Development of HCI as Immature Engineering ... 66
C h a p te r 2
Figure 2.1: The Planning and Control Domains of C^: Securing Interests through Advantage in Armed-Conflict and Specifying Goal States for Conflict Objects or Behaviours
.% ^ i y A -’«
Figure 2.3: A Model of a Conflict Control Task: the Vincennes
In cid en t... 87
Figure 2.4. A Representative Off-Load Table ... 100
Figure 2.5: A Representative SSGW Plan ... 101
C h a p te r 3 Figure 3.1: Development of an Expression of the Planning System Evaluation Problem and a Problem Hierarchy ... 108
Figure 3.2: A Human Interacting with a Computer to Perform Work .. 109
Figure 3.3: A Planner Interacting with a Planning Aid to Produce Plans ... I l l Figure 3.4: Problem Hierarchy ... 113
Figure 3.5: OPS0.5 ... 113
Figure 3.6: O PSl ... 113
Figure 3.7: Design Work: Implementation of OPS0.5 and O PSl ... 114
Figure 3.8: Use and Increm entation of Problem H ierarchy and Evaluation Problem Expression: the case of OPSl ... 115
Figure 3.9: Increm ented Problem Hierarchy ... 116
Figure 3.10: A Student Interacting with an Off-Load Planning Aid to Produce Laboratory Off-Load Plans ... 117
Figure 3.11: Use of Other Views of Effectiveness to Support Late Evaluation: the case of OPSl ... 130
Figure 3.12: A Summary of Alternative M anners of Carry Forward in Evaluation: the Case of Late Summative Evaluation of OPSl ... 140
C h a p te r 4 Figure 4.1: Development of a General Graphical User Interface Object - a Menu Structure for Planning Tasks ... 155
Figure 4.2: User Interface Styles as Collections of Objects Supporting Design in the In stan ce... 157
Figure 4.3: A General Menu for Computer File Control Tasks ... 158
Figure 4.4: A Menu Structure for Work in General ... 163
Figure 4.5: A Menu Structure for Planning Tasks ... 166
Figure 4.6: Design Work Undertaken ... 169
Figure 4.7:...O PSl: Gantt Chart View ... 170
Figure 4.9: Use and Increm entation of A pplication R epresentations involving Problem Hierarchy, Pre-conception,
General Problem Element and General GUI Objects ... 172 Figure 4.10: Further Increm ented Problem H ierarchy ... 173 Figure 4.11: An Integration of General GUI Objects for Military
Planning Systems ... 177 Figure 4.12: OPS Us Menu Structure ... 179 Figure 4.13: S A T C O N l’s Menu Structure... 181 Figure 4.14: Iterative Specification of a Menu Structure for O PSl ... 186 Figure 4.15: Iterative Specification of a Menu Structure for SATCONl 188 Figure 4.16: A Summary of A lternative Manners of Carry Forward
in Specification: the Case of Menu Structures for OPSl
and SATCONl ... 190
C h a p te r 5
Figure 5.1: An A lternative Conceptualisation of Design Work
T a b l e s
C h a p te r 1
Table 1.1; Characterisation of HCI as Craft and Engineering ... 31
C h a p te r 2 Table 2.1: A Conflict Control Task as Performed by USS Vincennes' C^ System on July 3rd, 1988 ... 85
Table 2.2: An Hypothetical Planning Task as Performed by a Possible, Future C^ System ... 92
C h a p te r 3 Table 3.1: Performance Indices for the Evaluation of Laboratory Off-Load Planning Worksystems ... 121
Table 3.2: Actual Performance of OPS0.5 ... 124
Table 3.3: Required Performance of O PSl ... 125
Table 3.4: Actual Performance of OPSl ... 126
Table 3.5: The Conformance between Required and Actual Performance of OPSl ... 127
Table 3.6: Indices of Human Factors and Software Engineering Aspects of the Effectiveness of Laboratory Off-load Planning Systems ... 136
Table 3.7: An Assessment of OPS I s Effectiveness from a Human Factors and a Software Engineering Perspective 139 C h a p te r 4 Table 4.1: A General Requirement for M ilitary Planning Systems .. 174
Table 4.2: Selective Instantiation of Domain Analysis for Off-Load Planning and Satellite Construction Planning at UCL ... 175
L • - «ic" - *-r. -. ' . '
C h apter 1 Forms o f HCI and Z ero—> B u ild
C h a p te r 1.
F o rm s o f H C I a n d th e Z ero --> B u iId S tra te g y
S u m m a r y
In recent years, a num ber of difficulties designing interactions betw een m ilitary personnel and their command and control (C ^) systems have been identified. These difficulties are persistent and have been attributed to a lack of carry forw ard betw een procurem ent projects.
The discipline which must respond to these difficulties by achieving greater carry forw ard is Hum an-Com puter Interaction (HCI). A discipline, here, is taken to com prise know ledge supporting practices addressing problems. W ithin this view of a discipline, carry forward may be initially conceived as the r e a lis a tio n of a com bination of knowledge, practices and problem s, that is, an achievem ent of knowledge that in actual fact supports a number of practices and so in actual fact addresses a number of problems. The notions of discipline and carry forward, then, are closely related (since a discipline which has yet to realise an effective com bination of
know ledge, practices, and problem s has little basis for claims of discipline status). Consequently, an analysis of different forms of HCI, that is,
different com binations of knowledge, practices and problem s may com e to reveal how carry forward may be achieved in different manners. Such an analysis may also serve to explicate the nature of the difficulties with the procurem ent of C^ systems and suggest how HCI as a discipline may
r e s p o n d .
In this thesis, it is suggested that lack of carry forward is an integral part of one particular form of HCI - im plicit HCI Craft. Lack of carry forward is simply a corollary of designing in a certain way. As a matter of fact, rather than principle, lack of carry forward tends to be related to, and to go
together with, 'soft' design problem s, personal skills and expertise and iterative im plem entation and testing. In recent years, many interactions betw een m ilitary personnel and their C^ systems have been designed in ju st such a manner.
Chapter 1 Forms o f HCI and Zero—>Build
G reater carry forw ard requires the construction of a fundam entally different and more effective com bination of know ledge, practices and problems. There is a need to reconstruct all the elements of the discipline t o g e t h e r , to devise knowledge representations that enable carry forw ard, a way of designing with knowledge so represented, and design problem s that may be effectively addressed by this knowledge and in this way. Attempts to modify a single element of the discipline in isolation of the others are unlikely to be effective, because com prehension of the relationships betw een knowledge, practices and problems is currently too low to predict, first, w hether a single discipline element (to be developed now) will indeed com plem ent other necessary elements (to be developed later), and, second, w hether a particular com bination, if ever realised, will indeed be effective in p ractice.
Before seeking to construct an additional form of HCI, it is necessary to make clear that attempts to progress HCI as a discipline may not assuage all of the difficulties with procurem ent all of the time. If a 'more advanced' form of HCI is developed, then this 'more advanced' form may be unable to address a ll the C^ design problems that are currently addressed by im plicit Craft. Some C^ problems may be so 'soft' and poorly specified that hand crafting may be the most effective manner of address, and so lack o f carry forward may ju st have to be accepted and accommodated. Consequently, it may be unrealistic to expect greater carry forward to be universally achievable. However, progress at the discipline level may be expected to assuage at least s o m e difficulties with procurement some of the time. Part of progressing HCI is the selection of 'harder', better-specified design problem s that may be effectively addressed by 'more advanced' know ledge and practices, and the directing of 'more advanced' HCI towards these p r o b l e m s .
In this thesis, greater carry forward is sought through a form of HCI term ed inform al HCI Engineering. Informal HCI Engineering is different from current best practice in that design work addresses general classes of design Problem and Instances o f general classes of design P r o b l e m r a t h e r than ju st problem instances which are related to other instances in some, unspecified way. Consequently, informal Engineering is of interest with
C h apter 1 Forms o f HCI an d Z ero—>B uild
respect to carry forward since, in principle, it offers a d d i t i o n a l
opportunities to develop and apply knowledge to design. Specifically, it offers additional opportunities to support: (i) the abstraction of general requirem ents from instance requirem ents; (ii) the production of general specifications in response to general requirem ents; and (iii) the
instantiation of general specifications for p articular instances. Further, the knowledge applied in support of design may concern c la s s e s of design Problem , rather than ju st instances or a poorly specified range of
instances. In addition, inform al Engineering also provides an a d d i t i o n a l way o f reasoning about the com pleteness and/or selectivity with which design Problem instances are addressed - reasoning with respect to a rele v an t class.
The strategy for the developm ent of informal HCI Engineering is 'Zero— >build'. That is, an attempt is made to develop knowledge about cla ss e s of Problem and apply such know ledge to general requirem ents and general specificatio ns i m m e d i a t e l v and from nothing (or near nothing)^. The Z ero—>build strategy is adopted to ensure that the knowledge acquired (inform al models of C ^) indeed supports the desired practices (inform al ab straction , specificatio n , sp ecialisation , in stan tiatio n and evaluation) w hich indeed address the desired problem s (general Problem s concerning m ilitary personnel interacting with com puter equipm ent to m anage arm ed-conflicts effectively). The Zero—>build strategy is also adopted to ensure that the Problems selected (aspects of C ^) are indeed sufficiently hard to be effectively addressed by inform al abstraction and specialisation etc. In addition, the Zero—>build strategy is adopted to enable refinement of the thesis’ objectives. Since the desired manner of carry forward is to be realised from near nothing ( ‘zero’), the initial specification of the form of HCI to be realised is itself inadequate. Initial realisations of combinations of knowledge, practices and problems ( ‘builds’) may be com pared and contrasted w ith current best, but carry -fo rw ard -d eficient practice, in order to reveal more precisely the characteristics of the ‘more advanced’ form of HCI that is sought. W ith current knowledge, neither the
com patibility of know ledge - practice - problem relations, nor the hardness of design concerns may be established a priori. The Zero—>build strategy recognises that, for the moment, an appropriate com bination of know ledge.
C h apter 1 Forms o f HCI an d Z ero—>B u ild
practices and problems must be largely selected on a trial and error basis, or, at best, rules of thumb.
In essence. Z ero—>build provides an opportunity to consider im m ediately, and on the basis of case evidence, the potential effectiveness in practice of the means of carry forw ard envisaged. Im portantly, such considerations are not simply deferred, or reduced to consideration of effectiveness in principle. Z ero—>build ensures that the work proceeds breadth-first and realises know ledge, problem s and practices in combination. Given the inadequacy of current understanding of the relations between HCI know ledge, practices and problems, an attem pt to develop one of these elem ents in depth, but in isolation from the others, is fraught with difficulty. With current knowledge, it is difficult to predict whether a single discipline elem ent (to be developed now) will indeed com plem ent other necessary elem ents (to be developed later) and that the com bination will indeed be effective in practice. For example, it is difficult to predict the usability o f certain knowledge representations in advance of tests with the intended designer population (Bellotti, 1988) or the efficacy of such re p re se n ta tio n s in advance.
A consequence of adopting the Zero—>build strategy with the lim ited resources of a PhD is that, for the moment at least, it is only possible to address s e le c te d aspects of design Problems and to develop minimal know ledge representations with which to support design work.
C onsequently, to m axim ise the opportunity to practise effectively, any know ledge must focus upon the most inform ative and easily conceived aspects of C ^, and it is necessary, for the moment at least, to work with know ledge o f a prelim inary kind and selective address of design Problem s. A lso, the individual who develops the know ledge representations (the ‘researcher’) must also conduct the practice (be the ‘designer’). Failure to do so may result in precious resources being wasted making explicit the tacit understanding o f the know ledge acquired and dissem inating this understanding to ‘desig n ers’, assum ing, of course, that such understanding may be made explicit at this stage. An additional consequence of pursuing the Zero—>build strategy with limited resources is that only a limited
C h apter 1 Forms o f HCI an d Z ero —> B u ild
context, rather than actual problems addressed in a com m ercial context. Finally, given limited resources, the effectiveness in practice of the means of carry forward realised must be assessed in a cost effective manner.
Thus, for the moment at least, it is necessary to work with judgem ents and suggestive em pirical reports, rather than allocate resources to more conclusiv e (but prem ature) evaluation m ethods.
O f course, the adoption of the Zero—>build strategy now does not preclude the adoption of other strategies later. For example, once knowledge - practice - problem relations are better com prehended and the nature of problem ‘hardness’ are better specified, a m ore ‘top-dow n, d ep th -first’ strategy more conventional in academic research may be more
a p p r o p r i a t e .
W ith the limitations of the Zero—>build strategy in mind, this thesis develops a prelim inary conception of the domain of (hence p re conception). A conception, here, is taken to be a set of concepts for form ulating design Problems. The pre-conception is used to support two attem pts to realise carry forward in a m anner characteristic of inform al HCI Engineering. The first attempt involves the evaluation of U niversity College London's (U CL’s) prototype system for planning the off-load of men and equipm ent during hypothetical am phibious operations (O P S l). The second attem pt involves the specification of a partial menu structure for m ilitary planning systems generally, and its instantiation for O PS l and a prototype m ilitary satellite construction scheduler (S A T C O N l), also reconstructed at UCL. For each attempt at carry forward, the work conducted is reported as an illustrative case history. (The case histories illustrate key characteristics of the m anner of carry forw ard sought). Each actual case history (of work conducted in an inform al. Engineering manner) is juxtaposed with an hypothetical case history (of how
C h apter 1 Forms o f HCI an d Z ero—>B uild
There is little hope that the Z e ro ^ u ild strategy will realise the perfect form of informal HCI Engineering at the first attempt, if for no other reason than the nature of the objective is poorly specified at the outset. Indeed, as later chapters reveal, the first attem pt appears to fail, and only at the second attem pt is anything like inform al HCI Engineering realised. H owever, zero-build may usefully dem onstrate the feasibility and potential of this form of HCI with particular reference to carry forward.
By virtue of its prelim inary, selective and reconstructive nature, then, this thesis may genuinely attem pt to specify, realise and illustrate inform al HCI Engineering im m ediately. This thesis reflects an exploratory exercise which, refining its objectives as it proceeds, seeks to advance HCI
know ledge, practices and problem s together by illustrating a com bination of these elements that, judging from the case evidence, appears to be effective in practice. The inevitable lim itation o f the Zero—>build strategy is that none of the individual elements are realised in a highly selective way. For example, an alternative thesis, following a more ‘top-down, depth-first’ strategy, could have developed a model of C^ more thoroughly, and sought to verify its scope and content, and assumed that other work would subsequently construct ways of using the model and identify problems to address with it. This thesis makes no argument against the adoption of such an alternative strategy, once more is known about knowledge - practice - problem relations and the nature of problem
C h apter 1 Forms o f HCI an d Z ero —>B u ild
1.1. D iffe re n t F o rm s o f th e D iscip lin e o f H u m a n - C o m p u te r I n t e r a c t i o n
1.1.1 D iffic u ltie s in D esig n in g S y ste m s
A num ber of difficulties in designing hum an-com puter interactions for systems have been identified (Holman, Young & Dorrington, 1987). These difficulties include: (i) re-design during and after installation; (ii) cost escalation; (iii) built-in obsolescence; and (iv) project slip. Given the current concern with the level of defence spending and the changing nature of m ilitary com mitments, such problems are pressing. However, they are not new. Indeed, such problems arise all too often and appear resistant to rem edial action.
The persistence of such problems has been attributed to a lack of 'carry forward' (Jordan, Lee & Cawsey, 1988; Grundy, 1988). That is, in lay terms, despite the best efforts of those involved, the developm ent and application of know ledge is inadequate - procurem ent projects are failing to learn enough from previous research or development work. To develop the technical view of carry forward necessary for this thesis, it is necessary to consider the nature of the discipline which must respond to these
difficu lties with procurem ent - H um an-Com puter Interaction (HCI).
1.1.2. C a r r y F o rw a rd a n d H C I as a D isciplin e
Chapter I Forms o f HCI and Zero-->Build
Figure 1.1(1): The Nature of a Discipline (after Long & Dowell, 1989)
Problems
.^^mc.c\:-:;''.i
K' v 'I',*-Practices - ' : ^ ' - - ' r ' w \
mm# « _______
mm a #
Knowledj^':; :
%
%
##
S i n c e the n o tio n o f c a rry f o r w a r d fo c u s e s u p o n th e r e la tio n s b e tw e e n the p r i n c i p a l e le m e n t s o f a d i s c i p l i n e - k n o w l e d g e , p r a c tic e s an d p r o b le m s -th is c h a r a c t e r i s a t i o n o f H C I as a d i s c i p l i n e e n a b le s an in itial te c h n ic a l v iew o f c a rry fo rw a rd as the r e a l i s a t i o n o f a c o m b i n a t i o n o f k n o w le d g e ,
p r a c t i c e s and p r o b le m s , that is, an a c h i e v e m e n t o f k n o w l e d g e th a t in fact s u p p o r ts a n u m b e r o f p ra c tic e s , an d so a d d r e s s e s a n u m b e r o f p r o b le m s (see F ig u r e 1.1 (ii). T h e n o tio n s o f d is c ip lin e and c a rry fo r w a r d , then, are
c lo s e ly re la te d , s in c e a d is c ip lin e w h ich has yet to re a lis e an e f f e c tiv e c o m b i n a t i o n o f k n o w l e d g e , p r a c t i c e s , a n d p r o b l e m s , a n d r e p r e s e n t e d k n o w le d g e such that it may be re -u s e d , has little basis fo r c la im s o f d i s c i p l i n e s t a t u s .
Figure 1.1 (ii): Carry Forward in HCI
practice 1 problem 1
knowledge present'n practice
2
problem 2
practice n problem n
C h apter 1 Forms o f HCI an d Z ero—> B uild
interacting with computers to perform work effectively". This view of HCI is different from previous work, notably Long & Dowell's "Conception of HCI" (1989) and Dowell & Long's "Conception for HCI " (1989), in that it m akes explicit the various potential meanings of the phrase 'general design problem '. This difference, im plicitly acknowledged in Long & Dowell (1989), follows from a less extreme position with respect to assumptions about the determinism of HCI's design concerns. Long & Dowell state that the discipline of HCI addresses the 'general design p r o b l e m of humans interacting with com puters to perform work
effectively" p. 15 (1989). The 'general design problem', here, implies a set of public, shared problems which are of interest to the HCI community as a whole, regardless of which form of the discipline individuals perceive them selves as practising (p. 18). In contrast, Dowell & Long provide concepts for formulating "a more formal expression of the [HCI] g e n e r a l design pro b lem [this author’s italics] which an Engineering discipline would address" p. 1521. This latter 'General Design Problem' (this author's capitals) is that addressed by only some HCI practitioners, specifically, HCI engineers, and, by im plication, not other kinds of HCI practitioner. Indeed, some HCI practitioners explicitly conceive the problems they address in a d i f f e r e n t manner to the General Design Problem ' (see, for exam ple, Storrs,
1989). In the characterisation of the discipline adopted for this thesis, HCI as a discipline is taken to address design problems' to make clear the distinction between the general design problem ' (com m unity-w ide set) and The 'General Design Problem ' (super-ordinate class for engineers)^, and yet explicitly accom m odating for both.
1.1.3. T h e P re c is e , T e c h n ic a l View o f C a r r y F o rw a rd
H aving initially indicated the nature of carry forw ard and considered the close relationship between it and the status of HCI as a discipline, let us now consider the nature of 'carry forw ard' more precisely.
Carry forward, for this thesis, is taken to refer to the development, re-use and increm entation of application representations (see Figure 1.2). To
C h apter 1 Forms o f H C I an d Z ero—> B uild
com prehend this characterisation, it is necessary to partition the knowledge that comprises the discipline of HCI. HCI knowledge may concern issues of substance, that is, the interaction to be designed and the work to be performed, or methodological issues, that is, h o w the designing is to be done (Long & Dowell, 1989). Knowledge representations may fulfil different functions in carry forward (Long, 1987). A b a s ic know ledge representation is one that does not directly support design. It is not referred to by a designer, unless the designer's task is performed
incorrectly, or the designer questions the basis for some other know ledge rep resen tatio n w hich is referenced directly. Thus, a basic representation enables and supports the developm ent of other, interm ediate, or
Chapter / Forms o f HCI and Zero—>Build
Figure 1.2: Carry Forward as the Development, Re-use and Incrementation o f Application Representations to Transform Design Representations
KEY
= relating to design problem 1
= relating to design problem 2
substantive basic represent'n
develop
substantive application represent'n
m etnod!
develop m ethod'l application ^ - - - - basic
represent'n rep resen t'n
r
re-use
u se/increm ent
metnod'i _ develop m ethod'l
re-use --- application ^ --- basic
use/ represent'n rep resen t'n
increm ent
y
initial represent'n
design
target represent'n
N o t e th a t, a c c o r d i n g to this v ie w , o n ly a p p l i c a t i o n r e p r e s e n t a t i o n s m a y be i n c r e m e n t e d (a d d e d to as a re su lt o f d e s ig n ) a n d r e - u s e d ( r e f e r e n c e d in o r d e r to d e s ig n first o n e i n s ta n c e and th en a n o t h e r ) . F u rth e r, a ta r g e t r e p r e s e n t a t i o n is n o t in c r e m e n t e d or re - u s e d in c a r r y f o r w a r d , b u t is e n h a n c e d as a re s u lt o f c a rry fo rw a rd . In a d d i t i o n , the d e v e l o p m e n t and r e v i s i o n o f b a s ic r e p r e s e n t a t i o n s are not c o n s i d e r e d to c o m p r i s e p a rt o f c a r r y f o r w a r d .
W h e n r e p o r t i n g a tte m p ts to r e a lis e c a rry f o r w a r d (as w ill o c c u r f r e q u e n t l y later in this th e sis, it is u se fu l to c h a r a c te r is e th e fo rm and c o n te n t o f d i f f e r e n t ty p e s o f b a s ic , a p p l i c a t i o n an d t a r g e t r e p r e s e n t a t i o n s .
C h apter J Form s o f HCI an d Z ero—>B u ild
(ch aracterisatio n s of designing), models (rep resentatio ns w hose attrib utes bear system atic relations to attributes of designing), rules (which diagnose or prescribe selected aspects of designing), analyses (which represent the problem atic features of designing) and specifications (w hich represent the d esirable features of designing). Initial and target representations may take the form and content of requirements (technical descriptions o f a desired artefact) and specifications (technical descriptions of the actual artefact to be, or which has been, implemented).
To illustrate the technical view of carry forward ju st presented, let us con sid er carry forw ard in a m anner characteristic of conventional, applied science and as characterised by Long (1987) (see Figure 1.3). In such an approach, a theory (a basic representation, and a sort of model) supports the developm ent of guidelines (application representation, and sort of rule, such as Gardiner & Christie (1987)) by following
'p articu larisatio n ' procedures. Given a prelim inary ‘w ish -list’ (in itial representation, and a requirem ent), the guidelines directly support the production of a design for a prototype (target representation, and a specification) according to 'synthesis' procedures. In this exam ple, the guidelines may re-used - by applying them to the design of other systems. The guidelines may also be incremented, since their use may reveal
add ition al exceptions, application conditions, or novel in terp retatio ns^.
^The concern of this thesis is carry forward of s u b s t a n t i v e knowledge. For these purposes, simple reports of carry forward may assist clear exposition. C onsequently, future reports of carry forward do not explicitly
C h a p ter 1 Forms o f HCI and Zero—>Build
Figure 1.3: Example 1: Carry Forward in Conventional, Applied Science
KEY h eo ry
haRin mn'n
= relating to design problem 1
nodel]
: relating to design problem 2
develop
guideline (appl'n rep'n rule)
use/increm ent
particular'n procedure
wish-list (initial rep'n,
requirem ent) design
sy n th e sis procedure
increm ent
sketch target rep'n, specific'n)
Chapter I Forms o f HCI and Zero—>Build
Figure 1.4: E xam ple!: Carry Forward in Potentially M ore Effective Applied Science
KEY
= relating to design problem 1
= relating to design problem 2
theory (basic rep'n, m ode
devel
guideline PUM solution Space
(appl'n rep'n (appl'n rep'n appl', rep'n,
rule) m odeh ramework)
u se/ increm ent
u se / increm ent]
u se / increm ent
1 . __________ 1
dsh-list initial rep'n.
equirem ent) design specific'n)
O p p o r t u n i t i e s fo r c a rry f o r w a r d are d e t e r m i n e d by th e d e s ig n c y c le . E a c h t r a n s f o r m a t i o n b e t w e e n d e s i g n r e p r e s e n t a t i o n s is s u p p o r t e d by d i s c i p l i n e k n o w l e d g e an d so o ffe rs an o p p o r tu n ity fo r c a r r y f o r w a r d (see F i g u r e 1.5). T h e c o n c e p tio n o f H C I d e sig n u sed in this th e sis is a less precise, in fo rm a l v e r s i o n o f S a lte r's c o n c e p t i o n (1 9 9 4 ). T h e l o o s e n i n g an d in fo rm a l
e x p r e s s i o n o f the c o n c e p tio n is r e q u ire d in o r d e r to a c c o m m o d a t e all f o r m s o f H C I. T h is c o n c e p tio n c h a r a c te r is e s H C I d e s ig n in te rm s o f n o n - t e c h n i c a l a n d t e c h n i c a l d e s i g n r e p r e s e n t a t i o n s an d p r o d u c t s . N o n - t e c h n i c a l
p r o d u c t s , d e v e l o p e d fro m th e u se r's p e r s p e c t i v e in c l u d e a c l i e n t ’s
r e q u i r e m e n t an d th e fin a l a r te f a c t. T e c h n i c a l d e s i g n r e p r e s e n t a t i o n s a re d i s t i n g u i s h e d as i n s t a n c e r e q u i r e m e n t s , g e n e r a l ( c l a s s ) r e q u i r e m e n t s , g e n e r a l ( c l a s s ) s p e c i f i c a t i o n s a n d i n s t a n c e s p e c i f i c a t i o n s ^ . T h e s e d e s ig n r e p r e s e n t a t i o n s an d p r o d u c t s a re l in k e d t h r o u g h p r o c e s s e s o f
i n t e r p r e t a t i o n , c h e c k i n g , a b s t r a c t i o n , s p e c i f i c a t i o n , s p e c i a l i s a t i o n , i n s t a n t i a t i o n , i m p l e m e n t a t i o n , o b t a i n i n g , t e s t i n g a n d a s s e s s m e n t . T h e r e are , th e n , at m o st, fo u r te e n o p p o r tu n itie s to a p p ly k n o w l e d g e in s u p p o r t o f
Chapter 1 Forms o f HCI and Zero-->Build
d e s i g n - tw o o p p o r t u n i t i e s p e r t r a n s f o r m a t i o n , o n e t r a n s f o r m a t i o n g o i n g f o r w a r d th r o u g h th e d e s ig n c y c le , o n e t r a n s f o r m a t i o n is r e v e r s e ( s e e F i g u r e 1.6).
F igure 1.5: The H CI Design Cycle (after Salter, 1994)
assess
abstract
interpret
analytically
general problem
eneral specific'n specify
instantiate instantiate
analytically
instance specific’n problem
instance specify
implement fcheck
abstract
obtain
client test
Chapter I Forms o f HCI and Zero—>Build
Figure 1.6: Opportunities to Develop, Use and Increment Applications Representations to Transform Design Representations
Key
1
,2
: = opportunityapplication rep'n
1 1, 12
general eneral
pecific'n problem
specify/assess analytically
instantiate/ abstract
instantiate/ abstract
1 3 ,1 4
basic application
rep'ns rep'ns instance
specific'n
application bas rep'ns rep
problem
instance specify/assess
analytically
implement/ obtain interpret/
check
client
requirements artefact
1 , 2
C h apter 1 Form s o f HCI an d Z ero—> B u ild
forw ard, may serve to further explicate difficulties with procurem ent and suggest the scale and nature of possible responses.
1.1.4. Crafting and Engineering Hum an-Com puter Interactions
for C2
This section characterises HCI both as an immature and a mature Craft discipline, and also as an immature and a mature Engineering discipline^. M aturity, here, reflects an assumption that, in practice, some forms o f HCI tend to precede, and support the development of, other forms of HCI. Thus, one form of HCI may be particularly associated with, and be regarded as, in practice, an interm ediate step to another. For example, in practice, i m p l i c i t know ledge tends to precede, and support the developm ent of, e x p l i c i t
know ledge. Sim ilarly, in practice, explicit knowledge o f design problem i n s t a n c e s tends to precede, and support the development of, explicit and inform al knowledge of c l a s s e s of Design Problem. Further, i n f o r m a l knowledge of c l a s s e s of Design Problem tends to precede, and support the developm ent of, f o r m a l knowledge of cl a ss e s of Design Problem. Long & D owell's characterisation of alternative forms of HCI is taken to offer initial characterisations of im m ature (im plicit) craft and m ature (form al)
E ngineering and a starting point for further discipline analysis.
This thesis extends the initial characterisation of im m ature (im plicit) Craft and m ature (form al) E ngineering, adds characterisations of m ature
(explicit) Craft and im m ature (inform al) Engineering and pays special attention to carry forward within each form of HCI (see Table 1.1). In essence, the difference between HCI Craft and HCI Engineering Craft is conceived as addressing i n s t a n c e s of design problem related to other instances in poorly specified ways, whereas Engineering is conceived as addressing c l a s s e s of design problem. Immature craft addresses problem instances i m p l i c i t l y , and m ature craft addresses problem instances
e x p l i c i t l y . Immature Engineering addresses classes of Problem i n f o r m a l l y , and mature Engineering addresses classes of Problem f o r m a l l y . The
inform al/form al distinction, here, expresses the fact that know ledge may or may not be acquired and represented according to the rules of
verification recognised by the HCI com munity.
C h apter 1 Form s o f HCI an d Z ero—> B u ild
Table 1.1: Characterisation of HCI as Craft and Engineering
Form of HCI
E l e m e n t o f D i s c i p l i n e
I m m a t u r e ( I m p l i c i t ) C r a f t
M a t u r e ( E x p l i c i t ) C r a f t
I m m a t u r e ( I n f o r m a l ) E n g i n e e r i n g
M a t u r e ( F o r m a l ) E n g i n e e r i n g K n o w l e d g e i m p l i c i t ,
fragm ented
e x p l i c i t , s t r u c t u r e d
e x p l i c i t , s t r u c t u r e d , c o h e r e n t , in f o r m a l
e x p l i c i t , s t r u c t u r e d , coherent, formal
P r a c t i c e s implementing & t e s t i n g
in t e r p r e t in g , c h e c k in g , s p e c i f y i n g , a s s e s s i n g , o b t a in in g , implementing & t e s t i n g
i n t e r p r e t i n g , c h e c k in g , a b s t r a c t i n g , s p e c i a l i s i n g , s p e c i f y i n g , a s s e s s i n g , o b t a i n in g , implementing & t e s t i n g
f o r m a l i s i n g , v e r i f y i n g , in t e r p r e t i n g , c h e c k in g , a b s t r a c t in g , s p e c i a l i s i n g , s p e c i f y i n g , a s s e s s i n g , o b t a i n in g , implementing & t e s t i n g
D e s i g n P r o b l e m s
soft, relations to other design p r o b le m s u n c le a r
somewhat soft, one of a loose network of design problem in s t a n c e s
somewhat hard, one o f a
hierarchy of informal General Design Problems
hard, one o f a hierarchy o f formal General D esign Problems
E x a m p l e B a s i c
R e p r é s e n t o n s
e d u c a tio n a l background, values, purposes
p e r s p e c t i v e s , p o s i t i o n s
in f o r m a l f ra m e w o r k s, informal models
f o r m a l fr a m e w o r k s, formal models E x a m p l e
A p p l i c a t i o n R e p r e s e n t n s
i n t u i t i o n s , experience o f extant systems
h e u r i s t i c s , interface styles
informal general p r i n c i p l e s , informal generic user interface c o m p o n e n t s
formal General D e s i g n
P r i n c i p l e s ( f o llo w i n g D & L 89) D e s i g n
R e p r é s e n t o n s
client reqt., ar te fa c t
client reqt., a r te fa ct, instance reqt., instance s p e c ’n
client reqt., a r t e f a c t, instance reqt., instance s p e c ’n, general reqt., general sp ec’n (all informal)
client reqt., a r t e f a c t , instance reqt., instance s p e c ’n, general reqt., general s p e c ’n (all formal) R e a s o n i n g
A b o u t
C o m p l e t e n e s s o f T a r g e t R e p r e s e n t n s
not open to public scrutiny
with respect to a lt e r n a t iv e i n s t a n c e
r e p r e s e n t a t i o n s
with respect to a s u p e r - o r d i n a t e c l a s s
r e p r e s e n t a t i o n s , but informally
with respect to a s u p e r - o r d i n a t e c l a s s
r e p r e s e n t a t i o n s , and formally
C h apter 1 Forms o f HCI an d Z ero—>B u ild
1.1.4.1. Immature (Implicit) Craft
In HCI as im plicit craft, interactions between users and their com puters are generally hand-crafted, bespoke designs for a single named system
produced in response to individual requirem ents, and often developed through a practitioners' personal, even idiosyncratic, approach to
im plem entation and testing. Such practices are supported by know ledge that rem ains fragm ented, largely im plicit and within the heads o f 'm aster' craftspeople (Jones, 1970). The relations between the problem addressed in any instance and other problems is difficult to ascertain, since such
relations typically remain implicit. Dowell & Long cite the example of Bornât & Thimbleby developing a text display editor called 'Ded' (1989). The problem instance addressed within implicit HCI Craft is one of the
com munity-wide set of design problems. For example, for Bom at &
Thimbleby, the problem was to design a text editor which would enable the user to enter text, review it, add to it, to reorganise its structure and to print it. The problem addressed by Bornat & Thimbleby is self-evidently within the scope of HCI - it concerns the rate at which the computer gives
feedback to user key presses, in relation to changes to the position of the cursor or the shape of text characters. Their problem is not an
instantiation of the 'General Design Problem ' addressed by HCI engineers (super-ordinate class), since the craftsperson's expression of th eir design problem instance is incom m ensurate with Dowell & Long's expression of the General Design Problem for HCI Engineering. For example, some concepts from Dowell & Long's General Design Problem', such as 'domain' and 'task quality' (see Chapter 2), do not appear in Bornat & Thimbleby's expression of the problem. Bornat & Thimbleby are more concerned with 'interactiv e behaviours' (w hich is a concept from the General Design Problem ) but not to acknow ledge any incom pleteness or selectivity in terms of Dowell & Long in their problem address. Further, although Bornat & Thimbleby appear to express their problem using concepts that are, on initial inspection at least, com patible with concepts from the General D esign Problem , closer exam ination reveals that apparently sim ilar concepts are, in actual fact, incommensurate. For example, 'ease of use' (Bornat & Thimbleby) appears, on initial inspection, to be similar to 'user costs' (General Design Problem). However, Bornat & Thimbleby's term 'ease of use' presumably e x c l u d e s 'ease of learning' (another widely used
concept) but i n c l u d e s maximum perform ance achievable by an
C h apter 1 Forms o f HCI an d Z ero—> B u ild
'user costs', in contrast, appears to mean the opposite, that is, to i n c l u d e costs incurred learning' but to e x c l u d e the 'task quality' achievable by an ex p erien ced user^.
This thesis also suggests that, in practice, the problems addressed by
im plicit Craft are 'soft' design problems, that is, problems that are difficult, or impossible to specify well. This addition to Long & Dowell's
characterisation of HCI, and its relation to Dowell & Long's conception requires clarification. Dowell & Long suggest that "the extent to which hum an behaviour is determ inistic for the purposes of designing
in teractiv e com puter-based system s needs to be independently established" (p. 1517). They suggest that human behaviour is determ inistic in at least some respects and to some degree and usefully so, and so the possibility of an Engineering discipline should not be ruled out, in principle (p p .1519 and 1533). They argue that, if the General Design Problem currently appears to be 'soft', then this may be symptomatic of the early stage of the d iscipline's developm ent, rather than the G eneral Design Problem 's
indeterm inism and com plexity (pl533). This thesis does not disagree with this position. But, it does suggest that, in practice, the softness/hardness of the com m unity-wide set of design problems may vary considerably, due the variable resources available for design (in terms of time, personnel and know ledge). Thus, the super-ordinate class of Design Problems for
engineers may not, in practice, be co-extensive with the com m unity-w ide set of design problems. W hatever the 'hardness' of the General Design Problem (super-ordinate class) is found to be in principle, so long as design w ork is constrained by limited resources and rationality is bounded^, so the G eneral Design Problem and instances thereof will be a sub-set of the range of design problems addressed by the community as a whole.
Hopefully, this sub-set will be a large sub-set, but its size is difficult, if not im possible, to determ ine a priori. Indeed, its eventual size may in part depend upon how well HCI Engineering is realised. Thus, this thesis adopts a position that is consistent with the pluralistic sentiments of parts of Long & Dowell, and with the assertions that determinism of design concerns is a
^Consideration of the status of Bornat and Thimbleby's design problem is of course hampered by the fact that the scope of the design problems
addressed by craftspeople may be difficult to delim it precisely, since the nature of this problem remains largely im plicit.
Chapter 1 Forms o f HCI and Z ero -> B u ild
key f a c to r in the e f f e c tiv e n e s s o f a lte r n a tiv e fo rm s o f H C I and th a t the a c tu a l d e g r e e o f d e t e r m i n i s m re m a in s to be re s o lv e d . H o w e v e r, this t h e s is is c o n c e r n e d w ith e f f e c t i v e n e s s in p r a c t i c e , r a t h e r th a n p r i n c i p l e , a n d s e e k s to c o m p r e h e n d all fo rm s o f H C I fo r th e ir m u tu a l b e n e fit (s e e later), r a t h e r than e n c o u r a g e c o m m i t m e n t to the d e v e l o p m e n t o f on e f o r m o f H C I in p a r t i c u l a r (fo r m a l E n g i n e e r i n g ) (se e F ig u r e 1.7). F r o m th e a s s u m p t i o n th a t, in p ra c tic e , th e d e t e r m i n a c y and c o m p l e x i t y o f H C I ’s d e s i g n c o n c e r n s v a rie s , it fo llo w s th a t d if f e r e n t fo rm s o f H C I are m o s t e f f e c tiv e in p r a c tic e f o r a d d r e s s in g c e rta in c o n c e r n s at c e rta in p o in ts in tim e. (T h is i s s u e is c o n s i d e r e d f u r t h e r t h r o u g h o u t th is s e c t i o n . )
Figure 1.7: Differential Effectiveness and Co-existence of Different Forms of HCI
high
Effectiveness in Practice
low
immature
mature (explicit)
immature (informal)
mature (formal) Engineering (implicit)
Cralft
Engineering Craft
soft hard
Determinacy and Complexity of Design Concerns o f HCI
Chapter I Forms o f HCI and Zero—>Build
'g u a r a n t e e d ' by th e r e p u t a t i o n , tra c k r e c o r d an d s u r v iv a l o f th e h u m a n 'e x p e rts' th a t e n a b le it (see F ig u re 1.8). L o n g & D o w e ll give the e x a m p le o f a c o lle a g u e g iv in g B o rn a t & T h im b le b y so m e a d v ic e (1989). T h u s , in
im p l i c i t C ra ft, d e s ig n w o rk (if it m ay be c a lle d su c h ) tr a n s f o r m s a c lie n t's r e q u i r e m e n t s in to an a r t e f a c t d i r e c t l y , th r o u g h a p r o c e s s o f i m p l e m e n t i n g a n d t e s t i n g ( p r o t o t y p i n g ) . T h e a p p l i c a t i o n r e p r e s e n t a t i o n s u p p o r t i n g th is t r a n s f o r m a t i o n is th e d e s i g n e r ’s o w n e x p e r i e n c e and e x p e r tis e . It is n o t d i f f i c u l t to p e r c e iv e h o w r e lia n c e on su ch m e c h a n is m s m ay fail to a c h i e v e c a r r y f o rw a rd . F o r e x a m p le , th e in te re s ts and m o v e m e n ts o f h u m a n
e x p e r ts m a y not m a tc h p ro je c t n e e d s, a rte fa c ts m ay be d iffic u lt to a c c e s s or be p r o t e c t e d by I n te l l e c t u a l P r o p e r ty R ig h ts , and i n d u c tio n m ay be
in c o m p le te . T h u s , lack o f c a rry fo r w a r d is an i n h e r e n t risk in i m m a t u r e H C I craft, if not an in te g ra l p a rt o f this p a r tic u la r fo rm o f HCI. F u rth e r, lack o f c a rry fo rw a rd is tied to the fact th at, sin c e im p lic it C ra ft k n o w l e d g e is i m p lic it, th e k n o w l e d g e its e lf is no t o p e r a tio n a l, g e n e r a l i s a b l e or
g u a r a n te e d to a c h ie v e its in te n d e d e ffe c t ( L o n g & D o w e ll, 1989). C a rry f o r w a r d r e lie s on i n t e l l i g e n t r e a s o n i n g by d e s i g n e r s , w h ic h ,
u n f o r t u n a t e l y , is n o t a v a i l a b l e to p u b lic s c r u tin y an d the d e s i g n e r s t h e m s e l v e s m ay o n ly h a v e l im ite d in s i g h t s in to t h e i r th in k in g .
Figure 1.8: Carry Forward in Immature (Implicit) HCI Craft
KEY
= relating to design problem
: relating to design problem 2
e.g.advising & intuiting/ leaming-by-doing
_[
client's requirement
experience.
code skills and
expertise libraries
e.g. copying/ storing
.g. expert walkthroughs/ coding direct from
discussions with client
C h apter 1 Forms o f HCI an d Z ero—>B u ild
The suggestion that im plicit Craft provides only an im plicit, highly personal and concrete manner of carry forward does not imply that im plicit Craft does not have a place or is to be rejected as necessarily ineffective. On the contrary, as a matter of fact, and for at least some problem s some of the time, im plicit Craft may be the most effective form of HCI available. Some design problems may turn out to defy specification in principle, or conducive to im plicit Craft in practice. For example, it may be a novel problem , posed by an idiosyncratic client who requires an artefact im m ediately and does not require absolute reliability. Although, in
principle, the problem could be better specified and addressed more effectively later - later may be too late for some design work. Thus, C^ design as im plicit Craft may constitute a com bination of knowledge, practices and problem s that may be effective within certain technical realities and logistic needs. In this sense, HCI as im plicit Craft may
constitute a necessary and coherent response to such realities and needs. Indeed, im plicit Craft appears to have been responsible for many
innovative and effective interactions and for the rapid spread of
Inform ation Technology in C^ over recent years. Immature craft may also offer useful support to other forms of HCI (see later). The difficulty is that, since, in practice, im plicit knowledge and practice tends to precede explicit know ledge and practice, carry forward through people is too often the only manner of carry forward available. That is, since im plicit Craft tends to em erge before other forms of HCI, the only practical way of developing artefacts may be directly from client's requirem ents and only a single m anner o f carry forward - through experience and expertise - may be available in support. Implicit craft offers ju st one of the opportunities to carry forward that, taken together, all the forms of the discipline of HCI could offer (see Figures 1.8 and 1.6). But at least it offers one.
G enerally speaking, im plicit HCI Craft appears to characterise much of HCI as it has been practised with respect to C^ systems. C^ systems are
C h apter 1 Forms o f HCI an d Z ero—> B u ild
practisin g design as o n l y an im plicit Craft. The technical meaning of Jordan, Lee & Cawsey's phrase 'lack of carry forward' (1988) is ‘carry forw ard in only the im plicit craft m anner’.
At this point, it should be clear that, since lack of carry forward is
associated with the early stages of a discipline's development, attempts to achieve greater carry forward in must seek to progress HCI as a discipline. G reater carry forw ard requires the construction of
com binations of know ledge, practices and problem s that are fundam entally different from that of the im plicit Craft. There is a need to devise
know ledge representations (both basic and applications), ways of
designing with know ledge so represented, and design problem s that may be effectively addressed by such knowledge and in those ways. Attempts to modify a single element of the discipline in isolation from the others are unlikely to achieve the result required. Indeed, such unco-ordinated interventions may disrupt the coherence of im plicit Craft and threaten its effectiveness. For example, making im plicit Craft knowledge explicit may have little impact on design in the absence of any new practices to apply this knowledge, or problems to which it may be applied. Any explicit know ledge acquired may fail to be recruited by the unm odified, im m ature practices of implement and test, or fail to be carried forward by human experts through advice giving and induction into the com munity. Effort spent making craft knowledge explicit may simply be wasted unless its associated practices and problems are also considered and modified to g e t h e r .
It should also be clear that attempts to progress HCI as a discipline may not assuage all of the difficulties with procurement all of the time. If a more 'advanced' form of HCI is developed, then this more 'advanced' form may be unable to address all the C^ design problems that are currently addressed by the implicit Craft^. For technical or logistic reasons, some C^ problem s may be so 'soft' and poorly specified that any approach other than hand crafting may be frustrated, and so lack of carry forward may have to be accepted and accommodated. However, the same assumptions about the
^The term 'advanced' here reflects the view that some forms of HCI may, in practice, be pre-requisites for the development of other forms of HCI. It is not suggested that replacing experienced, skilled craftspeople with
