Engineering works: what is (and is not) “engineering” for interactive computer systems?

ABSTRACT

What does it mean to “engineer” an interactive computer system? Is it about the team doing the work (that they are engineers), about the process being followed, about the application domain, or what? Is engineering about managing complexity, safety or reliability?

For physical artifacts, it may be possible to achieve consensus on how well engineered a product is, but this is more difficult for digital artifacts.

In this talk, I will offer some perspectives, both positive and negative, on the nature of engineering for interactive computer systems

and, at least implicitly, the nature and future of the EICS conference series.

Author Keywords

Engineering; HCI; safety; reliability; professionalism.

ACM Classification Keywords

H.5.2 [Information Interfaces and Presentation]: User Interfaces – Interaction styles.

General Terms

Human Factors; Design; Reliability; Verification.

INTRODUCTION

The aim of this short paper is to facilitate discussion on the role and value of engineering in relation to interactive computer systems.

It arises, in part, from an activity at the most recent IFIP WG2.7 / 13.4 (User Interface Engineering) working meeting: to develop a short video to communicate the value of engineering for user interfaces. It also arises from discussions I have had with various people on the nature and scope of the EICS conference. Both activities have generated more heat than light. It is, intentionally, not a well engineered argument for a particular position, but a series of vignettes putting forward different cases, for and against particular views of engineering in relation to interactive computer systems (ICS). My intention, which may or may not be realized, is that the community should establish a better shared understanding of the nature, value and role of engineering in the ICS context.

If it’s done by engineers then it is engineering

I am a Chartered Engineer. I started my career as a Graduate Trainee Engineer, at about the time the Finniston report [7] was published. That report emphasized the importance of engineering to the future of the economy, and also argued strongly for the status of professional engineers. Within the UK, that is a battle which has now been lost: “anyone in the UK may describe themselves as an engineer. Seeking to regulate or legislate on the use of a now common term is recognized by the Engineering Council as totally impractical.” [6] So, at least in the UK, anyone can call themselves an engineer, and – by extension – claim that what they are doing is engineering. A subset can make a stronger claim: that we are accredited as professional engineers. But is what any of us do “engineering”? Let us consider definitions of engineering.

Engineering: definitions

A dictionary definition of engineering is: “The application of scientific and mathematical principles to practical ends” [14]. The emphasis in the Engineering HCI Community of ACM is on “the application of scientific knowledge and rigorous design methodology to reliably predict and, thus, help improve the consistency, usability, economy and safety of solutions to practical problems” [1]. Both of these definitions focus on principles and rigor for addressing practical problems. Clearly, these principles should apply in the design of complex, safety-critical systems [10]. It is much less clear what it means to engineer the user experience, in terms of fun or affect (a theme in this year’s call for papers). The science of fun is poorly developed, the mathematics of fun even more so. User experience is not so well understood that it can be reliably predicted or delivered consistently without extensive iterative testing, which is standard ICS development practice, and not particular to an engineering approach.

The importance of iteration in iCS

Most HCI text books assert that iteration is essential in the design of ICS. Rogers et al [12] focus on four main phases of developing interactive systems: establish requirements; design alternatives; prototype; and evaluate. Iteratively. Best practice in the development of ICS includes requirements gathering and user testing, neither of which is particularly amenable to the application of scientific or mathematical principles, although both can be done rigorously and are essential to the delivery of systems that are safe and usable.

Tools such as CogTool [13] bring an engineering rigor and prediction to important aspects of user interaction with interactive devices, based on task performance. Similarly, model-based approaches to system development [9] support the task-based development of ICS. However, none of these “engineering” approaches take account of the softer, but equally important, aspects of the use of ICS, including the full user experience, how the ICS fits within its broader context of use, and how people conceptualise the activity the ICS is designed to support [2]. Without taking such aspects of use into account, the engineering of ICS runs the risk of delivering solutions to the wrong practical problems.

A case study: CHI+MED

The CHI+MED programme [5] provides an interesting object of study in terms of engineering ICS. CHI+MED is studying the design and use of interactive medical devices: safety-critical devices such as infusion pumps that are themselves moderately complex, and are used in highly complex settings. There are many aspects of these devices that can be subjected to an engineering approach, including modeling their safety properties [4] and formal verification [8]. Such approaches are necessary, but not sufficient. There are many aspects of the use of such devices in practice [11] that need to be understood and designed for. Without systematic study of the use of devices in context, and rigorous description of the “problem”, which defines requirements for the next generation of systems, and without careful testing of device prototypes, it is easy to deliver solutions that are verified by not validated [3]. There is a risk that by separating off “engineering” approaches to ICS, the engineering becomes distanced from the practical problems that it is intended to address.

Conclusion

There is an argument, based on the above, that engineering is the servant of design – that the user needs are identified outside the engineering process, that the engineer’s job is just to make the design as conceived by others work (ensuring that the system performs as intended – traditionally referred to as ‘verification’). This seems at odds with the broader view of software development lifecycles that development is iterative [3], and is concerned with considerations of usability, utility and experience (all of which are arguably elements of ‘validation’), which should also be concerns for engineering.

The title of this paper, “Engineering works”, is a play on words. One reading is a claim: that engineering makes things better; that it provides assurance that the proposed solution to a problem (an ICS) is well engineered: that it will not crash or permit the system to get into unsafe states, and will manage complexity well. The second reading is as a noun, “works”, qualified with an adjective, “engineering”; engineering work is needed when things have gone wrong, or need maintenance. In the context of EICS, I suggest that both meanings pertain: that engineering can make complex systems work well, but that the engineering approach needs active maintenance to remain relevant to other aspects of ICS design and to avoid becoming narrow and irrelevant.

ACKNOWLEDGMENTS

This paper has benefitted from discussions with many people, but the viewpoints put forward are my own. CHI+MED is funded by EPSRC EP/059063/01.

REFERENCES

1. ACM (n.d.) acm.org/communities/engineering/ accessed 17/4/13.
2. Blandford, A., Green, T. R., Furniss, D., & Makri, S. (2008). Evaluating system utility and conceptual fit using CASSM. J. Human-Computer Studies, 66(6), 393-409.
3. Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61-72.
4. Bowen, J. & Reeves, S. (in press) Modelling Safety Properties of Interactive Medical Systems. EICS 2013. To appear.
5. CHI+MED (n.d.). chi-med.ac.uk.
6. Engineering Council (n.d.). Status of Engineers. engc.org.uk/statusofengineers.aspx ac. 17/4/13.
7. Finniston, H. M. (1980). Engineering our future: report. HM Stationery Off.
8. Masci, P., Ayoub, A., Curzon, P., Harrison, M., Lee, I., Sokolsky, O. & Thimbleby, H. (in press) Verification of Interactive Software for Medical Devices: PCA Infusion Pumps and FDA Regulation as an Example. EICS 2013. To appear.
9. Meixner, G., Paternò, F., & Vanderdonckt, J. (2011). Past, Present, and Future of Model-Based User Interface Development. i-com, 10(3), 2-11.
10. Navarre, D., Palanque, P., Ladry, J. F., & Barboni, E. (2009). ICOs: A model-based user interface description technique dedicated to interactive systems addressing usability, reliability and scalability. ACM Trans. CHI, 16(4), 18.
11. Rajkomar, A., & Blandford, A. (2012). Understanding infusion administration in the ICU through Distributed Cognition. biomedical informatics, 45(3), 580-590.
12. Rogers, Y., Sharp, H., & Preece, J. (2011). Interaction design: beyond human-computer interaction. Wiley.
13. Teo, L. H., John, B., & Blackmon, M. (2012). CogTool-Explorer: a model of goal-directed user exploration that considers information layout. Proc CHI. 2479-2488.
14. The Free Dictionary (n.d.) thefreedictionary.com/engineering accessed 17/4/13.