|
These are the slides I used for a guest lecture to second year undergraduates at EECS, Southampton. They are taking a compulsory HCI module, but some find it hard to understand how this fits in, or is relevant, to other aspects of the computer science curriculum.
I was asked to talk about some of my own journey from mathematician to human–computer interaction, and my own view of the place of HCI in computing as a whole.
Mathematics was my academic 'first love' and my mathematical credentials are pretty strong winning a bronze medal as a member of the British Team to the 1978 International Mathematicial Olympiad (rare for a comprehensive kid) and finishing my Maths Tripos in Cambridge in 2 years. So it is, perhaps, a bit of an odd transition from pure maths into human–computer interaction!
However, I also had an interest in computers from an early stage. I described the first proper computing book I read (with the exception maybe of Ladybird's "How it works: The Computer"); it was a systems analysis book, written probably in the 1960s that I borrowed while on a childhood holidayto Weston-super-Mare. The book included a vignette about the author going into a company to advise on a new computerised printer system, only to find a much more economic and effective socio-technical solution. This vignette can be found in HCI online! "Early lessons - It's not all about technology". I also did a computing A'level (rare at the time), going for an afternoon a week to the local FE college (certainly not a school subject then!).
Skipping quickly past the importance of Open University programmes while making the fire each morning as a child, a year studying statistics in Cambridge, a couple of years mathematical modelling of electrostatically charged agricultural sprays in Bedfordshire, and a year programming Cobol in Carlisle (experience I have returned to continually through my academic career), I ended up as a researcher in York looking at the formal modelling of user interfaces ... hence the maths to HCI transition.
My very first impressions of formalism in computer science was that, with a few exceptions, it seemed incredibly light weight - voluminous, but not deep. However, I then realised that the difference was one of purpose. In pure maths you just get to choose your own problem, whereas as soon as you apply things i the real world, this adds its own constraints; you don't just get fun nitty problems, but relatively large-scale problems where you may need to find compromise solutions.
You can see thsi even with formal areas of computing, the difference between:
- raw computability - whether it is possible to compute something. e.g. the Halting Problem
- algorithmic complexity - in order of magnitude terms how long it takes e.g. that sorting is O(n log n), but bubble sort is O(n2)
- practical complexity - that some 'impossible' (NP) problems can actually be solved for all data that occurs in day-to-day life, and that even bubble sort may be useful if data is almost sorted
As the problems become more applied, more practical, they become messier and in many ways harder.
The talk and slides then focused on a single diagram that tries to capture the way that real computer systems are always human–computer systems, and that algorithmics always sits within systemics.
As an example, I looked at event-based copmputing.
Most computer sceicne undergraduate computing courses on algorithms and data-structures have a heavy bias towards sequential coding: loops and arrays; maybe only encountering event-based programming as a complex area in a third year distributed computing course. In contrast, those on business computing courses often start off with Visual Basic, much derided by pure computer scientists, but because they do so, they encounter event-based programming from day one.
In fact, while in some ways more messy and complex than sequential programming, event-based code is pretty much the heart of all real-world applications from low-level coding of real-time systems, networking and distributed systems, to user-interfaces, web architectures, and big-data.