Workshop on Effective training and education for human computer interaction Glasgow, 23rd & 24th March 1998

Personal position statement
HCI education and training

Alan Dix

School of Computing, Staffordshire University
PO Box 334, Stafford, ST18 0DG, UK


As I've written this position statement, what I originally thought would be a couple of bullet points has expanded rather!

I'll first of all explain why I'm interested in HCI education, then talk about some general points about the current climate in UK higher education as it relates to HCI and following on from that look at what are the essentials of HCI teaching. Next I'll look at the relationship of HCI and computing science, first of all the problems of the macho CS approach to HCI (and the equally naive HCI response) and then at the way HCI can help teach computing science. Finally I'll look at HCI research a why HCI is good for research in general and what makes good HCI research.

Why I'm interested in HCI education

I've got three main reasons for being interested in HCI education:

It's my job!
Most of our undergraduate and postgraduate courses in the School of Computing at Staffordshire University include HCI as core modules or as popular options. In addition, we have several courses where HCI is a central feature: BA in Interactive Multimedia, BSc Computer Science with Multimedia Systems, MSc Computing Science (Human Computer Interaction) and MSc in Technology for Learning.
Professional Interest
As a long-standing researcher in the field and part of the British HCI Group Executive I'm interested to see a vibrant and knowledgeable HCI community in the UK and world wide.
As an author
The second edition of Human-Computer Interaction (Dix, Finlay, Abowd and Beale, 1998) is now out. I'd obviously like to see lots of HCI courses out there, especially if they are using my book! In addition, my co-authors and I would like to make the book web site a useful resource for others teaching HCI. For example, the OHP masters developed for the first edition of the book are all available from the site. A new development is a full free-text search of the text of the book, which acts as an instant reference for those with or without the book.

Some general problems

Diminishing resources

With resources per student in the UK shrinking by 50% in the last 10 years and little sign of improvement it is clear that something has to give in higher education. The key economic indicator is the number of student FTEs taught per hour of staff time. Intensive tutorial and laboratory sessions perform badly against this metric. So what future is there for an apparently resource intensive subject like HCI?

It is interesting to see some of the solutions in different position papers: group work (Barbara McManus and Stuart MacFarlane), CAL and web-based resources (Skip Basiel and Jean Vanderdonckt).

Perhaps one of the key problems is assessment as often HCI modules frequently require both a practical project and an examination. This is only tenable in the long term if modules are sufficiently large or if cost of assessment is reduced (for example by group projects).

Integration and modularity

In several position statements, most notably Mark Dunlop's there is consideration of the integration of HCI within other parts of discipline curricula. Later I'll look at some of the ways in which HCI examples can help across computer science, but there is a fundamental barrier to this in many institutions, namely modular degree systems. ideally some of the practical side of HCI could be taught and assessed within substantial projects including aspects of software engineering, real-time systems, information systems design, networking etc. However, this sort of teaching and assessment is al but impossible in most modular systems.

One possibility here is that the economic climate is forcing a re-evaluation of commonalty between modules. If University information systems can cope with it, this could lead to the unit of sharing being smaller course units rather than whole modules and shared objects of assessment and teaching becoming a preferred rather than disallowed option.

What's special about HCI education

Partly due to the shrinking resources, partly to changes in society there is an increasing emphasis on resource based learning, Internet and CAL materials, distance and life-long learning. So, let's imagine 95% of the material is on-line and only a couple of hours of actual contact time are available. What should you do? What are the essentials of HCI that you can't learn from a book or CD-ROM?

I guess there are obvious things like user-centredness and ... Or perhaps there is only one obvious thing user-centredness, from which much else follows. Techniques, follow once the philosophy is in place.

However, there are some additional things that I'd like to get over.

First and most important is excitement. This is true of any subject. How can you learn if you're not interested? As a teacher I need to breathe and live an excitement to motivate and inspire. After that they can learn things like task-analysis, dialogue design and organisational issues from books and other materials (but especially the odd good book!).

A key feature of generating excitement is usually story telling. HCI abounds with wonderful stories: comedies about interfaces that went wrong and tragedies about planes that crashed. It is especially good when, like fairy tales, they mix the reality we know well with the other that we only half-know: "have you clicked a web link and had to wait five minutes for it to appear" - heads nod - they are engaged - "well let's talk about how to make it better". Of course, in papers we have got to use fancy words like 'scenario', but what is really important for teaching and research are good stories.

As well as making them excited about HCI I want to make students intolerant. What! We live in an age which idolises tolerance of anything and everything (with the exception of course of strong belief in anything at all). But the reason that bad interfaces survive so long is that people don't even notice them. They expect computers to be difficult and, of course, blame themselves. The greatest gift to any HCI practitioner is a complete intolerance of anything and everything that makes life difficult for users. There is an eye-opening required that says "look at these things deeply, don't accept them, challenge them".

Its interesting that the other subject I've been most involved in the teaching of is statistics. Like HCI this requires a blend between a formal side (in HCI the computer, in statistics mathematics) and the real, problematic and hard to define world. It is not question of one or the other or even moving between the two, but of holding both sides in mind at the same time.

This dual nature, the importance of human- and technology-centred thinking, is one of the things I'd like to get across, by example and explicit discussion, so that neither side swallows up the other (more on this next).

HCI and Computing - uneasy bedfellows

As I work within a computing rather than psychology or social science framework, I'm particularly interested in the issues facing HCI within a computing curriculum.

Real CS men don't think about users

One of the key problems is clearly the macho CS approach that says HCI is not real computer science. Mark Dunlop and Andrew Monk also mention this in their position statements. Having worked in a variety of institutions the prevalence of this attitude varies widely.

In York, with a very traditional CS curriculum, the attitudes were strongly entrenched. Despite being one of the leading HCI research centres in the UK, many staff had a poor view of HCI an attitude which communicated itself to the students. I recall listening in on a six-form open day as a final-year student described the specialisms in the Department to potential entrants. "... Oh yes and there's HCI, but we try not to bother with that." It is frightening to think of the graduates going out who have never thought, and purposely avoid thinking, of the people who will use their systems. This is obviously storing up problems for those like Brian Buck who are trying to instil a professional attitude to user interface issues within industry.

In contrast, both Huddersfield and Staffordshire have a broader computing base with a strong information systems as well as computer science emphasis. There is still the normal partisanship between the protagonists of either views, but with somewhat more mutual respect (possibly not universal!). This is reflected in the attitudes of students and in both institutions HCI modules are core on many courses and HCI options are heavily subscribed.

That's just a implementation issue

The fault does not all lie with the CS side! there is a similar attitude amongst those in HCI (both educators and professionals) who regard the implementation of systems as a mere detail. "I built a SuperCard prototype why can't the programmers just build it." This attitude somewhat like that of the First World War Generals, fighting from their offices in Whitehall without ever experiencing the trenches.

Implementing systems is important and difficult, and without a clear idea of what is practical and achievable HCI design will be flawed. This is one reason why my co-authors and I felt it important to include a substantial part of a chapter on the resource limitations of computer systems.

The madness of method

Another conflict I find is that the 'design' elements of computing curricula emphasise strong methodologies - SSADM, modular formal refinement, OMT. I recall in 1992 when we were working on the first edition of Human-Computer Interaction being worried that the contents of our book did not advocate or follow such a method. However, my mind was put at rest when I was thumbing through one of the key textbooks on fluid dynamics. Despite the fact that in essence fluid dynamics boils down to a single set of equations (Navier-Stokes), there was no attempt to say "when you approach a fluid dynamic problem follow the following stages ...". Instead the book presented a bag of techniques that the professional mathematician would select from when addressing a problem. This is not to say there are no HCI methods, for example aspects of rapid-prototyping, user-centred design and task-analysis. However, there is not single formula to be applied. In mature disciplines there is a distinction between the theoretical tools and techniques and the professional's application of these. We do not need a formula approach to HCI, and I do not believe computer science should treat its practitioners as if they were the same as its raw material.

Who's afraid of the big bad while loop

Programming should be central to computing curricula of all kinds. Sadly, all too often I have heard final-year computing students say "I want to do a project, but I don't want any programming" - and this isn't just since I moved to 'softer' computing departments! Rather than seeing HCI as a soft option I feel the coding issues in HCI are some of the most complex in computing. One of my greatest problems in teaching HCI to CS students has been that they simply don't know enough computer science, much of the time is spent teaching them how to program. In addition, the programming paradigms for user interfaces are often quite different from those in traditional programming courses: event-driven programs require a different approach to algorithmics concentrating more on state and less on sequence and many ordinary graphics programs require low-level manipulation of colour and co-ordinate geometry.

One solution in more dedicated courses is to use an interface or prototyping language (e.g. Visual Basic or HyperCard) as a first programming language. There are certainly advantages to this in getting ideas of event-driven programming, but some of the 'nice' features of the underlying languages which make them easier to read can also make it difficult for students to grasp key programming concepts. It is often easy to do the first steps and for students to appear to be doing well, but it is often based on little deeper understanding. I guess this is not a reason to shy from using these languages, but does suggest care is needed in teaching. (In fact, many of the same problems happen with traditional teaching languages, which is perhaps why all those final-year CS students are frightened of coding.)

HCI and Computing - working together

Oh doom and gloom!

But happily, HCI and computing can work together. In particular, HCI can be very good as a way of teaching computing!

This is partly because it makes the inner workings of the computer visible and partly because the complexity of user interfaces force issues that are hidden by standard examples.

Programming again

I've already mentioned programming. Despite the fact that user-interface programming is hard, it s also very motivating. Writing programs that manipulate hidden arrays and variables is like making love in a space suit. As a programmer I often find it frustrating that HyperCard made me put virtually everything in (by default visible) fields on cards. But, boy, when things went wrong how happy I was to see the values sitting there. Indeed, what is the hackers first response to bugs? Formal analysis? Structured walk through? Component testing? No!! Print statements of course. One of the reasons LOGO was advocated by Papert was that it made algorithmics visible.

(Incidentally I recently spent frustrating hour trying to work out why the output of a interactive program was not visible, only to discover at the end that the text colour was the same as the background!)

Algorithmic complexity

When teaching CSCW courses I've wanted to talk about O(n) and O(n2) complexity of networking solutions. "Some of you have seen this before in your courses haven't you?" ... blank faces. "Haven't you ever talked about how long sorting or loops take?" ... blank faces. Oh well!

What's fascinating is that despite the fact that these are see as difficult topics (which is probably why all te CS students had forgotten it and why the IS ones never did it), students grasp them so quickly when faced with the much more solid world of HCI problems. A few examples of passing letters around either point to point or via a postmaster and they see the difference between O(n) and O(n2) messages. Time complexity also makes far more sense when you are waiting for the screen to update. Indeed, my biggest lesson in the importance of time complexity was a program I once wrote which took 3 minutes to process each character!

Networks and real-time systems

Simple groupware and user-interface examples clearly demonstrate issues like race-conditions. It is hard to comprehend these when the subject is a low-level protocol, but very obvious when you see lines in an on-line chat system get mixed up.

Formal specification

This is really an area where the standard examples gloss over real complexity. The stated aim of much formal specification is to describe 'what not how', but in practice virtually all example specifications effectively mirror the excepted code structure. Each part of the specification neatly refines down to a piece of code (actually rarely do they go that far), you put them all together and, hey presto, a program that does what you want! In fact that was just how I got my 3 minute per keystroke program.

In contrast, specifications of user-interfaces are by their very nature behavioural and the simplistic notions of refinement breakdown. Students would learn far more writing specifications of simple artefacts such as four-function calculators and electronic alarm clocks than stacks and queues. Furthermore, they soon find that they didn't understand the artefacts around them nearly as well as they'd thought - the formal specification has shown them something they didn't know before. This happens when I've taught formal methods in HCI, but I don't think specifications of stacks ever elicit much excitement.

HCI research

What's good about HCI research

I spend a lot of time with researchers, Masters and PhD students from all aspects of computing and beyond and have given lectures and seminars on research techniques and presentation skills. As I do this I keep realising that I am using HCI philosophy in many of these areas. What do you write in a reference? The standard answer is look at the relevant style guide (Harvard, APA etc.). A better one I find is to say "why do you have a reference in a document?". The answer is a human one - it is to satisfy the purposes of the document - to enable someone to find the article or book. When faced with new types of resources, web pages, CD-ROM etc., this sort of thinking is far more useful than "follow the guidelines". What is the difference between the abstract, introduction and final summary of paper? Again thinking about purpose makes it obvious. What about the format and structure of a whole PhD thesis? The purpose is to inform and convince (and of course it should be readable on the train to the viva!).

So, HCI is a good training for any researcher and academic!

What's difficult about HCI research

Being interdisciplinary HCI research has some special problems. Not least finding suitable examiners. Chris Johnson goes into these problems in some depth in his paper.. One would hope that all academics would be able to look and cross-disciplinary work and assess it in is broader context, but ...

In fact, there is a further problem in that although there are now many people who one would class as HCI people, there are increasingly PhDs where the subject is HCI & something else. Now we would hope that having suffered the problems of being inter-disciplinary for so long HCI experts would be more willing to deal with this sort of PhD ...

What's good HCI research

I often distinguish academic research from invention. Academic research may lead to an invention, but inventions may come independently. Inventions may be good, they may be produced by clever people, but an invention on its own is not built on, nor does it add to the body of knowledge in a domain. For an invention to be also research it must either be built upon analysis of preceding work or be analysed to yield its important lessons for the future.

I said earlier that I wanted students to be intolerant, to say of difficulties in interfaces: "look at these things deeply, don't accept them, challenge them". In addition, there is an extra step which is important for undergraduates and essential for research which is "understand them". Understand why it is bad to use (psychology and cognitive science), understand what it is in the system that makes it difficult (dialogue analysis, architectural design, programming and networks), and ask why it happened (methodology, organisational and political factors in design). The heart of academic research is deep analysis, it is from this that the final stage comes - how to make it better.