Controversy and Provocation

 

Alan Dix

alan@hcibook.com
www.hcibook.com/alan/

 

Keynote presentation at - HCIE2004, The 7th Educators Workshop: Effective Teaching and Training in HCI,
1st and 2nd April 2004, University of Central Lancashire, Preston, UK


Full reference:
A. Dix (2004). Controversy and Provocation. (Keynote) In Proceedings of HCIE2004, The 7th Educators Workshop: Effective Teaching and Training in HCI, (Preston, UK 1st and 2nd April 2004). ISBN 0-9541927-5-3
http://www.hcibook.com/alan/papers/HCIE2004/
More:
Download full paper (PDF, 27K) and presentation slides (PPT, 129K)
HCIE2004 workshop programme etc.
Alan's pages on HCI Education
 

avoiding the controversial

When the organisers asked me to talk at HCIE2004 they said "wondering if you would start off Friday morning's session by being controversial - as we know only you can ;-)". "Sure", I said, "but I'll not be deliberately provocative of course".

Well if I had wanted to be controversial I guess might have decided to talk about the way in which the new student fees regime in the UK was likely to lead to an intensification of a two tier system in University level education where the students from lower class backgrounds are served by underfunded understaffed institutions. This might have lead to a discussion of how it is that attainment at age 18, as measured by A’ levels is related more to social class than academic ability, yet is the only real means we have to select students for higher education. And perhaps I might have mentioned that one of the few ways to alleviate this social divide at 18 may be to abolish all school homework (which would get me the children’s vote) and to lengthen the school day with compulsory after-class activities (which may get a more mixed reaction).

However, as I didn’t intend to be deliberately provocative this all seemed better left out.

controversy - a debate between disciplines

However the words controversial and provocative made me think. What exactly do they mean. From the Shorter Oxford English Dictionary, here is an extract of the definition of controversy:

controversy: disputation, (prolonged) debate, esp. conducted in writing [L. contrversus (CONTRA-, vertere, vers- turn)]

Now in fact HCI has its roots in multiple disciplines, originally mainly psychology/cognitive science and computing, but more recently encompassing aspects of sociology, anthropology, management science, and more. These disciplines each brought their own methods and concerns and to some extent we could see the whole field of HCI as a (prolonged) debate, often conducted in writing.

In the early days HCI researchers and educators were drawn from different disciplines and brought their own academic cultures, theoretical models, methods of work and criteria for validity. A new generation of HCI people includes many who are 'pure' in the discipline. This has problems for theory as we have few theories of HCI as such and yet are losing our theoretical roots in our parent disciplines. Even more problematic it has problems for empirical methodology which has often drawn crudely from other disciplines, notably psychology, without adequately understanding the reasons these methods have validity.

So in the past people studied in other areas and then ‘became’ HCI people bringing in their own knowledge and knowing that they needed to learn from others and work with others to address interaction issues. Now we have people who have ‘done’ courses in HCI, usability engineering, interaction design ... but with what theoretical roots? In teaching terms this means we either give odd snippets of psychology or software engineering offering the students a sort of intellectual decoupage ... or we take professional practice such as heuristic evaluation and pass it off as something academic ...

... perhaps the best HCI education is no HCI education?

the vocational and the academic

This tension between the vocational and the academic, alluded to above, is one of the other key problems that face us both as educators and researchers. Every HCI paper must end with a set of guidelines or lessons for design, yet in other disciplines the science of empirical and theoretical work is allowed to stand in its own and is then interpreted in professional practice.

For example, as a mathematician I learnt fluid dynamics and have since then applied this on several occasions in professional practice. The text books and courses on fluid dynamics included real-life examples, but did not attempt to give a methodology for how to take a problem and apply the correct methods to obtain a result. Perhaps if I had studied plumbing this is what I would have got. Instead as an academic education I learnt a series of formal techniques. It was this toolbag of techniques that I applied, when faced with new problems using my own professional judgement evolving over time. This is not to say that there are not things that can be taught to aid the development of that professional judgement, but that within the academic discipline these two, the theoretical knowledge and professional judgement, are clearly separated.

I recall being faced with this issue when we wrote the first edition of "Human Computer Interaction". We had a software engineering angst ... where is the overall method? The book discussed software processes in one chapter, but we never gave a single method that encompassed all ... a sort of UML of HCI. Happily, we were not swayed by this and did not attempt to produce an overall this technique goes here approach. You may notice that in the recent third edition one chapter does give guidance as to a ‘typical’ interaction design process with indications of where different techniques fit. However this is explicitly a broad brush view with a focus on the trade-offs of real design and choices of techniques available ... not a painting by numbers approach. Furthermore, although more explicit techniques such as task analysis have their place in the process diagram, things such as cognitive psychology or understanding computational capabilities, do not have an explicit ‘space’ - the deeper theoretical knowledge is applied more diffusely.

Now this seems a standard argument of theory vs. practice, but this is almost always a false distinction:

theory is the language of generalisation

If we want to apply knowledge in new areas it is theoretical knowledge not procedural techniques we need to apply. Imagine I had studied plumbing. The things I learnt in fluid dynamics would have been largely irrelevant, sure the water flowing down the pipes obeys Navier-Stokes equations but I would always deal with similar pipes and so the effects of the equations can be reduced to a collection of lookup-values in tables of pressure losses and, at the level of household plumbing, rules of thumb. However, I would not simply learn a set of standard house plans for plumbing, but would also learn about the angle of drop needed for waste pipes, about the use of U-bends to avoid smells, the need to avoid high spots in a central heating run where air can accumulate. Without this theoretical understanding I would be unable to apply my knowledge to new plumbing problems.

For me applying fluid dynamics, I was not seeing slight variants of the problems studied in my text books. Instead I was looking at spray being emitted from nozzles and the sheets of water as they broke up, or at the airflows around a large fan for blowing spray into fruit trees. These were not in my textbook, but I could use the textbook to help me tackle these new, and very practical, problems because the textbook gave me the generic theoretical techniques I could apply.

Of course in my fluid dynamics textbook I did not find a discussion of the electrostatic and quantum mechanical effects that gave rise to properties of fluids such as viscosity. If I had needed to understand the flows of novel substances with strange properties then I would have needed this.

Even in a purely vocational course, the level of theoretical knowledge needs to match the expected flexibility of professionals during their working life. In HCI we have seen the move from green-on-black character terminals, through stand-alone GUIs, to the internet and now ubiquitous computing ... students who are taught only guidelines and similar more practical techniques have been sold short for their future careers.

just in time theory

Of course one of the problems is that as experienced HCI educators we have amassed a wide range of theoretical knowledge from many disciplines. Should we only accept students for HCI related courses only after they have done several degrees in pertinent disciplines? Clearly not, yet the range of theory that they may need to apply is so large how do we cope?

One partial solution I have used (but not in a consistent manner) is what I call ‘just in time theory’. These are small case studies or real scenarios the analysis of which introduces several theoretical concepts.

Note first though that real ‘examples’ from life are very different from the examples we often use in didactic contexts. The traditional way to teach in a grounded manner is to introduce some theoretical concept and then give a concrete example. Alternatively we may take a more dialectic approach: give an example that has some problem that the existing knowledge and techniques on the course cannot tackle and then teach a new technique or concept that ‘fills the gap’. It is not that we may not draw on particular real examples for either of these, but in order to have didactic effect we typically require them to in some way be simple or embody a single theoretical concept.

Note too that the second of these, problematic example followed by theoretical ‘solution’, is often the way we work in HCI and has a strong rhetorical effect - "look at these people bumping into the glass door, if the designers had only understood affordance ..."

However, real examples we encounter in professional life, rather than artificial or carefully selected ones, are more complex. They require multiple theoretical approaches in order to understand them and often are resistant to a simple ‘fix’. For me, I found myself forced into this by trying to explain some of the actual problems with technology I found around me in the classroom. I am sure many readers will have had similar class experiences.

One example of this a few years ago was a problem involving a particular version of Excel. After entering student assignments to groups ready for some group work I found I could not close the spreadsheet. After (live in front of the class!) analysing the problem it became clear that it was a combination of a not very visible mode and a closure problem. This led to a discussion of modes in general and also closure including the classic ATM ‘example’ (which incidentally is very nationally biased). In trying to understand how the problem came about in design we pondered on good deliberate reasons for it (often a useful heuristic for even the worst failures) and also the nature of the software engineering process and user interface architectures that lead to the clear errors in design.

This is reminiscent of Carroll and Rosson’s Claims Analysis which takes the implicit claim in an artefact that it is in some way fit for purpose and unpacks this into a number of theoretical claims that are necessary to understand or contribute to that fitness.

There are several critical features of this use of mini cases studies that make them just-in-time-theory. One is that they are used as an entrée into theory. The example is not reduced to guidelines or rules of thumb, but instead is unpacked to reveal the deep issues underlying the observed phenomena. Furthermore that theory is expounded in the context of a particular instance of use, so is motivated and grounded. However, these theoretical issues are not seen in isolation but in a the full ecological complexity of real life with trade-offs between different competing issues. Finally, the example may call for special-purpose theoretical understanding drawing on the root theories.

As an example of the latter, just recently I noticed that the toilet paper in our offices often got tangled, but on other times it would sit neatly in the holder. After a while I realised why. The holder held two rolls one on top of the other. When the lower roll was finished it fell through a hole in the bottom and the upper roll dropped into place. The tangling was due to the upper roll unwinding prematurely. The reason this only happened occasionally was due to the direction of the toilet rolls. If the two rolls were placed in the same way round, the unwinding of the lower roll during use also unwound the upper roll. In contrast, if they were placed opposite way round to each other, the unwinding of the lower roll actually tightened the upper roll. In discussing this with the cleaner we realised this was the same principle used on bicycles where some nuts have reverse threads so that they do not undo due to the wheels motion. Understanding this "why" is essential. The "opposite way round" rule only works if the rolls have a vertical axis. If the two rolls are on top of one another with a horizontal axis they need to be the same way round.

Note that just-in-time-theory in education is unlikely to deliver a ‘complete’ coverage of theoretical underpinnings. But of course in HCI what would such a complete coverage be -we may write things in our syllabi, but we know they are just a personal selection. Really just-in-time-theory fits better with what I call the T-model of education -giving students a broad knowledge of what is there, reinforced with deep theoretically and practically grounded knowledge in a few areas. The aim is not that the students know everything at the end, but that they feel a sense of mastery and feel able to find out what they need when they need it and to apply it well.

Of course I do not live up to my own educational ideals and far too often end up cramming too much into too little time!

Finally on just-in-time-theory, I believe, but have no experience except my own practice, that this is a good way of delivering case knowledge to practitioners. Imagine you are a designer faced with a particular design problem. You look up an interaction design example or pattern that seems to match your own situation, but like the toilet roll example, blindly following the apparent lesson in the example could lead to a poor or broken design. You need to understand the theoretical reasons why the design works in order to modify it for your own situation. If you have a broad knowledge to start with you may be able to do this yourself, but if examples are stored together with linked theory then the practitioner has the theory when it is appropriate.

provoking theory for HCI

Returning to my dictionary, an extract of the definition of "provocative" reads:

provocative: tending to cause provocation (of curiosity, anger, lust, etc.). [L PRO(vocare call)]

Now just looking at the first of these, tending to cause provocation of curiosity ... well what better thing could we aspire to in education!

However, looking also at the etymology "to call", I feel that I would like to call out for a seeking for our own roots as a discipline.

In Carroll’s recent collection "HCI models, theories and frameworks, the subtitle is "toward a multidisciplinary science". The chapters are largely about the different theoretical frameworks that contribute to HCI, but few of the theories would I say belong HCI as such Now it is not that we should have an all embracing theory of HCI that embodies all that is necessary from others. However, there do seem to be special properties of the interaction between people and technology that are only partially touched by current theory.

No wonder it is hard to teach HCI ... we don't really understand it!!

I guess Norman’s cycle is the most widely known theoretical model which is really about interaction, yet it is largely at a descriptive level - very hard for students to apply for themselves. However, in the restricted domain of information seeking, Information Foraging Theory is perhaps one of the most well developed frameworks since the Model Human Processor, so explicit understanding of interaction is possible!

Yet, in trying to make sense of more recent sensor based systems that do not require explicit intention the existing interaction models seemed just not to apply. Also in Lancaster, we well soon be deploying a large scale installation of situated displays in public places on campus. How are we to understand the interactions of multiple people with multiple displays in public and semi-public places?

Now I am sure we will get some understandings of these areas, but if I teach my students these understandings alone, then what happens in 5 years time or 10 years time when the technology changes? Their knowledge of situated displays will seem as dated as a discussion of key stroke sequences seems today. It is the fundamentals of the discipline that will carry them forward, some of which we still need to discover.

In a world where technology and human life have become more and more deeply entwined, HCI, or a generalisation of it, will be one of the key academic foundations. To serve this role HCI needs both to turn back towards its intellectual roots in other disciplines, but also to call out for its own.

further reading

I have written about the T-model for teaching and just in time theory in SIGCHI Bulletin education columns:
Dix, A. HCI Education - mastery. SIGCHI Bulletin, 35(2), March 2003, p.7.
Dix, A. HCI Education - just-in-time theory. SIGCHI Bulletin, 34(3), May 2002, pp. 7
Copies of all my SIGCHI Bulletin articles can be found at:
http://www.hcibook.com/alan/hci-education/
You can read more comment on social class and educational opportunity in several of these columns notably:
Dix, A. HCI Education - opportunities for change. SIGCHI Bulletin, 34(1), January 2002, p.7.
There is a description of the Excel mode error at:
http://www.hcibook.com/e3/casestudy/excel-mode/
The principle of trying to treat a bad feature as if it were deliberately designed, together with other uses of ‘bad ideas’ is discussed in more detail at:
http://www.hiraeth.com/alan/topics/res-tech/
I think the original paper about claims analysis is:
Carroll, J. M., and Rosson, M. B. Getting around the taskartifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems,10(2), 1992, pp. 181-212.
but there may have been conference or workshop papers before this.
Carroll’s theory collection is an excellent resource for more advanced teaching.
Carroll, J. (ed.) HCI Models, Theories, and Frameworks: Toward an Multidisciplinary Science. ISBN 1-55860-808-7. Morgan Kaufman, 2003
I think the earliest published version of Norman’s cycle and seven stages of action is in:
Norman, D. Cognitive engineering. In Norman D. and Draper, S. (eds.) User Centred System Design. Erlbaum, 1986, pp. 31-61.
Also it is well worth getting hold of UCSD. It has so many gems that were written when direct manipulation and graphical interfaces were still in their infancy, so is in some ways has a nostalgic feel today. However, the tenor of the chapters is focused on theoretical understanding of these new phenomena and is perhaps more transferable to more novel technology than much that has been written since.
Carroll’s collection includes a chapter by Peter Pirolli on information foraging theory and information scent, or if you prefer a more in depth treatment (not for the fainthearted) there is a substantial journal article:
Pirolli, P. and Card. S. Information Foraging. Psychological Review, 106, 1999, pp. 643-675.
I refer several times to editions of "Human-Computer Interaction" ... of course by that I mean ;-) ...
Dix, A., Finlay, J., Abowd, G. and Beale, R. Human-Computer Interaction, third edition. Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Chapter 5 has a broad brush model of design process and chapter 18 includes a discussion of low-intention interaction and the challenges this poses for interaction, task and interface architecture models. You can also read about low-intention interaction at:
http://www.hcibook.com/alan/topics/incidental/
I will put copies of slides and other links I can think of at:
http://www.hcibook.com/alan/papers/HCIE2004/


Alan Dix 24/3/2004