Harold Thimbleby. Press on and co�ee . . .

0

Introduction

Press On provides many ways of thinking clearly about the design of interactivedevices and provides many ways of thinking about interaction programming. It cov-ers the computer science fundamentals of the design of interactive devices, whichare typically complex things with buttons, like mobile phones and photocopiers,but they range from the very simple—like torches and guns—to the very complexlike word processors and the web browsers.

This book takes the view that we can build far better interactive devices than wedo now and that much of the initiative for better design can come from clear engi-neering creativity, knowledge, and perspectives based on sound computer scienceprinciples. Some things are possible or not possible, and competent computer sci-entists can work it out. Programmers can come up with solutions that would haveescaped users or designers with limited technical knowledge; programmers canbe more creative and more central in all areas of interaction design than anyonesuspected.

0.1 The Press On sandwichPress On is divided into three parts, like the layers of a sandwich. Programmingconcepts improve device design. That’s the meat—or the salad if you are a veg-etarian. But why do you want to improve design? Appreciating the complexityand impact of interactive devices is crucial to knowing what you want to improve.This context provides the two layers of bread to wrap the filling.

0.1.1 Is there really a problem?Computers have become smaller and smaller and are buried inside all sorts ofgadgets, from mobile phones to watches and ticket machines to completely novelgadgets that nobody knew were needed before they were invented. The first stepin making these things better is to understand why we put up with them as theyare. My emphasis throughout is on making things better. Problems are not themain thrust, but we do need to see them for what they are and why they areworth solving, because it’s a big culture shift to be solution-oriented: Press Onis a sandwich of motivation around a filling of real, working techniques.

1

Chapter 0 Introduction

I look at why we accept a system of poor design, upgrade, and obsolescencein computers, more than we would for any other type of product. I examine thepsychology and logic of using various items of technology and why they are theway they are. It’s a tangled story. If we can’t even understand things as simple asa digital clock, then we are not going to understand more complex things. For thatreason the book focuses on small-scale technologies.

Part I ends with chapter 4, “Transition to interaction programming,” which putsthe complaints of part I into perspective—reviewing the wider field of interactionprogramming—as well as introducing the role of programming in solving manyproblems. The programming language used in part II, JavaScript, is introducedand justified.

0.1.2 How can we design better?I introduce state machines and discuss how they can be modeled to provide uswith a simple and powerful way to analyze and design better user interfaces.State machines comprise perhaps 95% of interaction programming problems, andwe understanding them—whether they are represented as statecharts, graphs, ormatrices—lets us easily build and analyze better systems and generate accurateand up-to-date user manuals and interactive help.

State machines represent a fundamental idea, which will never be out of date.Any interactive system—past, present or future—can be understood from this per-spective. State machines are sufficiently general to describe what a device does aswell as what its user manual does. Getting them right is a major part of designinginteractive systems.

Some people, however, say state machines aren’t powerful enough for whatthey want to do. You probably wouldn’t want to design a full office applicationwith one, because it’d get too complicated to manage (that’s why all office ap-plications are hard to use). But for mobile phones, photocopiers, aircraft flightdecks, robots, medical equipment, home entertainment stuff, and so on—all thegadgets we encounter in everyday life—state machines are ideal design tools. Wewill show how state machines are easy to work with, particularly when we use ap-propriate methods. We will analyze some specific designs and identify and solvedesign problems—some quite creatively.

If you are a programmer, you’ll be pleased to see how relevant everything youalready know is to interaction programming. It’s time to use your computer sci-ence to make interactive devices easier to use for everyone.

0.1.3 How do we scale up to large design problems?I discuss the ethics of design in technology, presenting a case for a rethink. Ethicsis about how humans should interact. We have a lot to learn and put into practiceabout how interactive devices and humans should interact.

The design of interactive systems is complex, with people, technology and socialsystems all interacting, to say nothing of standards, obsolescence, market forces,

2

0.2. Principles

and just our ability to keep up to date. Things get out of hand quickly, and whatis surprising is not that things are awkward to use and can be improved, but thatthey work at all.

0.2 PrinciplesVarious principles in Press On are summarized at the end of each chapter. The finalchapter of the book summarizes the main themes of the book.

Good user interface design isn’t a matter of following a recipe you can get from acookbook: it’s an attitude, along with a bunch of principles, skills, and provocativeideas.

Nothing can provide definitive solutions; ideas and theories have to be insight-ful and provocative. Given real-world complexity, then, this book cannot be adefinitive solution to everything that can happen. No book could be. Instead, PressOn is provocative; through many examples, stories, and simple ideas and theories,it tries to shift your values and create new vistas where your design problems be-come new opportunities to do better.

Interaction programming is an endless subject. Like a magazine, Press On haslots of asides and boxes to provide background and interesting ideas. There isa lot of cross-linkage between topics; this is a visible sign of the intrinsic varietyand cross-disciplinary fertilization of design itself, but it also allows the book tobe read in any order, for sections cross-reference themselves to different contexts,perspectives, and ideas in other parts of the book. For those who want backgroundmaterial to go deeper, this book includes suggestions for further reading at the endof each chapter. Like all good books, Press On has a web site,

mitpress.mit.edu/presson

. Linkage looks like this—brief paragraphs o�set with a triangle marker. Linkageis a taken-for-granted part of the technology of books, along with tables ofcontents, footnotes, indexes, section and page numbering, even bookmarks. Allthese ideas make books easy to use and more useful. We’ll mention the historyof books and printing in section 4.2 (p. 96), because it is not only fascinating inits own right, it’s a good example of using design to make things easier—it alsosuggests a range of e�ective aids we can put into documents, such as user helpmanuals, to make them more useful. Interaction programming is everywhere,even in things that aren’t conventionally thought of as interactive.

. If all the linkage in this book were represented as buttons a user could press tojump around, the book itself would be interactive, much like a web site.Figure 8.8 (p. 246) provides a visualization of all the linkage in this book.

I hope you read Press On and are inspired that there are many ways to do a betterjob of design—indeed, any criticism of this book you have is your opportunity todo better. I want to give you an appreciation of how powerful simple computerscience is and how it can influence, for the better, anybody doing anything.

3

Chapter 0 Introduction

Box 0.1 What is interaction programming?Interaction programming is done by interaction programmers, programmers using their

specialist skills to design, analyze and program interactive devices used by people.

Interaction programmers find opportunities for redesigning interactive devices to

improve them, and they improve the tools and processes that support the design,

programming and evaluation of devices, and all associated activities.

They watch other people using interactive devices, evaluate them programmatically,

and think analytically about their internal structure. They and their programs work not

just with users, but with other designers, manual writers, trainers, and the many others

involved in evaluating, using and maintaining devices.

Conventional approaches to interaction emphasize working with users, and most

completely ignore the intricacies of programming. In contrast, interaction programming

is direct: it emphasizes being clear about design requirements and developing

dependable programs with rigorously assured and measurable usability properties.

Press On is aimed at interaction programmers who like computers and programming, who

want to know the principles of how to design, program, and understand interactive systems

so they are easier, more dependable, and more satisfying to use.

0.3 How to teach interaction programmingThe main way to teach any subject is to be enthusiastic about it and to encouragethe students to teach themselves. Interaction programming is a naturally excitingsubject, whether you are interested in fashionable devices like cameras and mobilephones, or are interested in making the world a better place by improving medicaldevices or the lives of elderly people coping with complex gadgets. Design issuesabound on the web, in interactive exhibits in museums, in burglar alarms, in air-craft, in cars, in ticket machines, in games, and throughout computer applications.

I usually run the course in two sets of eight to ten lectures. First, I teach bygiving lectures on the principles and background issues, simultaneously settingpractical coursework and encouraging students to choose topics that engage them.The second series of lectures covers theory and programming that the first course-works highlight where the students need to learn and work with in more depth.

Press On touches on a huge variety of material: human perception, environmen-tal issues, programming, mathematics, design, economics. It is great fun to teachstudents by encouraging them to pursue their own interests more deeply than asingle book can. If a student likes mathematics, there are plenty of mathematicalideas here that can be pursued further, even to postdoctoral research levels. Thesame goes for environmental issues: what are we going to do? Nobody knows.

Universities, departments, teachers, and students are all different, but if youwant to teach interaction programming, I believe you have to build things and getstudents involved. Often those things won’t work very well—and that’s the firstlesson! How can we build things, and what processes can we use, so that we canmake them better? Indeed, how will we know they are not good enough, and that

4

0.3. How to teach interaction programming

it is worth improving them? Thus coursework needs to get students engaged inthese issues and experiencing them directly. Too much of the literature on inter-action programming celebrates success; to be a successful interaction programmeryou need to know how to survive failure. Coursework is a great teacher, espe-cially when done in a supportive environment that pulls out the lessons from theexperience.

. The culture of success, and the way it encourages us to ignore failure isdeveloped in section 2.2 (p. 40).

Experience can be defined as what you get just after you need it. Students needexperience, which means they have to be able to stretch themselves into buildingsystems that will expose issues they don’t know how to deal with. Much like reallife, then, which a course on interaction programming should be training them for.

It is important to teach the material from Press On along with a course on re-search methods. It isn’t easy for students to organize their coursework or projects;it isn’t easy writing and doing research. What’s the difference between the journal-ism of a product review and critical, insightful analysis of a design? Coursework isoften seen as merely a way to get marks and to pass a course to go on to do the nextcourse. But how do you recognize when your work is really worth pursuing andother people would be interested in it? When would it change the way the indus-try works? When would it be worth developing a piece of student’s coursework topresent at a conference on interactive systems design? These are really importantresearch methods issues, and if Press On can be taught in an environment with aresearch methods course, the potential for improving the world—it surely needsimproving—is unbounded. Alternatively, teach Press On with a business courseso that the ideas students generate can be put into action in the business world asnew products and ideas.

This is a big book, covering a fascinating and complex area. If you find anyerrors, or if your teaching or doing coursework uncovers improvements, pleaselet me know by email. I’ll look forward to hearing from you.

In some universities, if the course does not finish with an exam, student atten-dance will drop off. If exams are needed, they are hard to mark! How can thepractical subject of interaction programming be assessed in a three-hour test? Agood question would be to ask students to write about their heroes of interac-tion programming and what they achieved. This is motivating stuff; it requiresthe students to read around the subject and to understand the achievements oftheir heroes. People who come immediately to my mind include: Bill Buxton,Stu Card, Joelle Coutaz, Chris Evans, Richard Feynman, Brian Gaines, Alan Kay,Brenda Laurel, Alan Newell, William Newman, Don Norman, Seymour Papert,Jef Raskin, Brian Shackel, Harold Thimbleby (who naturally comes to my mind!),and Terry Winograd. This is by no means a complete list, and if you are worryingabout important people I’ve missed, well, that shows just how important thinkingabout heroes is! What are the criteria for being a hero in interaction program-ming? Students should be asked to reflect on why they choose whom they do andasked why they didn’t choose some other people . . . learning is about joining thecommunity and knowing who’s who.

5

Chapter 0 Introduction

0.4 Devices, applications and product referencesI refer to specific products in this book. Mostly, I have chosen relatively cheap andcommon consumer devices, as this makes it easier for you to get involved. Al-though the narrative of this book covers many simple examples, bigger issues arebeing addressed. My approach is to start with real interactive devices, and as theyare real any reader can check that I have understood them, that I have representedthem faithfully in the discussion, and that I have obtained nontrivial and interest-ing insights. I cover a range of devices providing many different perspectives, andsome I have handled several times repeatedly in the book, but in different waysto illustrate the flexibility and generality of the approaches proposed. Each devicechosen is representative of the “state of the art.”

Some of the devices may seem obsolete. For this book, though, there are advan-tages. Manufacturers need not worry about criticism of devices out of production.Older devices are simpler, so most readers will be familiar with all the featuresthat they have—we don’t want to spend time on introducing features but on theunderlying interaction programming issues.

New devices grow out of earlier devices, so the design issues of the older stuffis still present in current and future devices. For instance, in 2007, one of thenew gadgets was the Nokia N95, putting into a single device a phone, a mediaplayer, a radio, a navigation system, two cameras, a calculator, some games, a helpsystem, as well as other applications. In one device it did things this book coversunder separate topics, but this book also discusses important ideas like featureinteraction and consistency, serious issues that combining separate applications inone device like the N95 raise with a vengeance. Our discussion of help systemsare way ahead of it too.

If I had used trendy examples, they’d only be obsolete sooner! Today’s CDs,which were originally promoted as lasting a lifetime, are already being replacedwith ones that are designed to self-destruct, as this solves the copyright problems(for the suppliers, that is, not for the users nor even the environment)—the ruleschange. Already, CDs are physically larger than the personal music players thatare replacing them. Although music players have pretty much the same user inter-face designs whether with or without CDs, in general the user interfaces of gadgetswill certainly change as we think of more exciting things to do—but the designprinciples will remain constant. This book is about those lasting design principles,not about today’s time-limited fashions, however superficially tempting fashionsmay be.

. Find out more about obsolescence and its impact in section 1.9 (p. 27).

. Box 10.1, “Why personal video recorders?” (p. 331) discusses the choice ofpersonal video recorders in more detail.

Getting a modern piece of technology to work at all, particularly in a commer-cial environment, is a miracle in itself; keeping an innovative stream of productsrolling off the production line, and hence keeping the manufacturer in businessto live another day, is more important than “perfection.” On the other hand, I

6

0.4. Devices, applications and product references

hope this book will help designers see how they can make products better, andby changing practices, make their products increasingly better over time.

A danger of referring to real products is that this book’s accuracy relies on howgood my understanding of the products is—how good is my reverse engineering?The manufacturers of these devices did not provide formal specifications—I hadto reconstruct them. While this is a weakness, any reader can check my resultsagainst a real device, its user manual (if adequate), or by corresponding with themanufacturers themselves.

An alternative might have been for me to build new systems and discuss themand the design insights they inspired. Here, there would be no doubt that thesystems were accurately specified—though the reader would not be able to obtainthem as physical devices to play with. But the problem would be that I might nothave implemented or thought about certain awkward features at all: I would bemisleadingly talking about, say, “mobile phones” when in fact I was only talkingabout the simple mobile phone that I implemented for this book. It would be hardto tell the difference between what I had done and what I should have done.

Although they get occasional mention as needed, this book does not specificallycover safety-critical systems, the design of devices like medical equipment, aircraftsystems, and nuclear plant control panels, nor does it cover mission-critical sys-tems, ones that, for instance, directly keep a business working. To cover these,we would have to skirt the legal minefields, an unproductive diversion from ourfocus. Nevertheless even small contributions to user interface design significantlyaffect health and safety for many people—and some readers will take hold of theideas in this book and use them for significant applications, like aircraft flightdecks or nuclear power-station control panels.

What of the future of interactive technologies? The interaction programming is-sues and problems of future devices are going to be essentially the same as the in-teraction programming issues and problems for today’s devices (to examine themin this book would take space to explain the unfamiliar domains). In the future,we will have implants, devices embedded inside our bodies: surely we will beable to control them, but we certainly do not want their design to drive us mad!We will want our exoskeletons—external robotic body enhancers—to be both nat-ural to use and safe. When we release millions of nanotechnology gadgets, we willwant to be sure they work as intended, especially when they interact with us andtheir environment. Why else have them?

7