Books & People

Books, People

Book Reviews

Links & More

	Print version
Related Links
	Harold Thimbleby's hompage
Background Links
	Books
	People

Book Review: Press On – Principles of Interaction Programming

Book | Author | Review

By Gerd Waloszek, SAP AG, SAP User Experience – June 27, 2008

This review takes a personal look at Harold Thimbleby's book Press On – Principles of Interaction Programming.

Book

Harold Thimbleby
Press On: Principles of Interaction Programming
The MIT Press, 2007
ISBN-10: 0262201704, ISBN-13: 978-0262201704

Design: UI Design

Author

Harold Thimbleby is Professor of Computer Science at Swansea University, Wales. He is the author or editor of a number of books, including User Interface Design, and nearly 400 other publications.
(From cover of Press On)

Review

Preface

Have you ever counted how many remote controls you have in your household? I just did that, and here is the result: I found 10 different remote controls (see figure 1).

Figure 1: I found ten different remote controls in my house

The remote control with the fewest number of buttons comes – unsurprisingly – from Apple: I counted just six buttons. I found that remote controls for radio sets typically have between 20 to 30 buttons, whereas remote controls for TV sets exceed that number, and some of their buttons have multiple functions. However, remote controls are just a small subset of the electronic devices and gadgets lingering in modern households. So I expanded my selection of interactive devices to include phones, calculators, thermometers and weather stations, translators, digital cameras, and more. This led to a collection of 29 devices, as shown in figure 2:

Figure 2: Collection of small devices in my household – not including my fax machine, copier, radio and television sets, computers and related equipment, and many more devices

Each of these 29 devices has a different set of controls and its own "interaction philosophy." Of course, this collection does not include all the devices that "live" in our household. There is also the camera that took these photos, a fax machine, a photo copier, two computers and related equipment, digital clocks, electronic scales, and many, many more devices and gadgets. I did not count them, but I would not be surprised if the number exceeded 100. Are we gadget collectors? No, in my opinion, we are just a typical European household.

But this is less than half of the story: When I leave my home, I am confronted by many more devices, be it at work, at the supermarket, or when I want to buy a train ticket. I can only marvel at how humans are able to cope with all this variety, a variety that absorbs so many of their cognitive resources and robs them of so much time (even though we are told the opposite – that these devices will make our lives easier). How much unused space must people have had in their brains a couple of centuries ago, free to be filled with imagination, dreams, and thoughts?

Introduction

Wow, that was a long preface to my review of Harold Thimbleby's textbook Press On! His book addresses exactly this issue, namely the variety of interactive systems and devices that surround us and how we can improve their design. The book cover tells us what we already know: "Interactive systems and devices, from mobile phones to office copiers, do not fulfill their potential for a wide variety of reasons – not all of them technical." It also offers us some consolation, since "in his book, Thimbleby shows that we can design better interactive systems and devices if we draw on sound computer science principles." That sounds like the difference between theory and practice. In theory, we have such well-designed devices. In practice, we have a chaos of devices, where each piece of equipment is handed differently. Of course, this chaos is not found everywhere, and there are "common" features or concepts shared by devices. For example, in figure 1, there are three remote controls with a red on-off button. The other remote controls in the picture, however, do not have such a clearly marked on-off button – and one of the three has a second red button, which might be confusing to some users. But before I start complaining and ranting, I should acknowledge that Thimbleby is well aware of the current situation and uses a number of "real" examples of bad design to illustrate this in his book. One such issue is that a device and its remote control follow a different interaction logic. I also own devices where some functions can only be operated on the device itself, while others can only be controlled with the remote control. For example, I can only adjust the volume of my TV set on the device, not with the remote control, which is completely absurd.

Thimbleby not only addresses the dilemma of hard-to-use devices with his book Press On, but also as as a lecturer at Swansea University, where he teaches future interaction programmers to design better devices. Thimbleby uses the term "interaction programming" instead of "interaction design," because he feels the latter term is too closely related to "industrial design," which in his opinion focuses on the look-and-feel of systems, rather than on their inner workings. He describes the target audience of his book as follows: "Press On is aimed at interaction programmers who like computers and programming, who want to know the principles of design, program, and understand interactive systems so they are easier to use." His design principles are based on "proven principles from computer science," such as finite state machines, graph theory, and algorithms. His intended audience consists mainly of computer science students who are used to formal approaches. Students of psychology or design will have more problems with the book's approach. As the book focuses on interactive devices and their modeling through finite state machines, one might also rightfully ask whether it is suited to interaction designers who primarily develop software applications. Thimbleby is well aware of the advantages and limitations of his approach, and I will return to this topic at the end of my review.

Walkthrough of the Book

According to Thimbleby, "Press On is divided into three parts, like the layers of a sandwich." The meat or the salad, that is, the middle part of the book, consists of programming concepts that help to improve the design of interactive devices. This constitutes approximately 60% of the book. "Two layers of bread wrap the filling" and provide the context for design. In particular, they address the question of why there is a need to improve design. But in spite of all the issues that Thimbleby looks at, his book is not problem-oriented but solution-oriented. His emphasis throughout the book is on making things better and he states: "Press On is a sandwich of motivation around a filling of real, working techniques."

Part I: Context

Part I: Context, or the first slice of bread, starts by taking a critical look at current design practices as well as the societal conditions under which design takes place. Thimbleby discusses topics such as how companies externalize cost to the disadvantage of national economies, the ecological issues arising from constantly buying new products and disposing of them and possible alternatives, further, how computers make (or lay the foundations to make) our society increasingly complex, and how giving individual interests priority over common interests may have severe consequences, for example, environmental problems. Then Thimbleby discusses how our perceptual habits lead to misjudgments about the usability and usefulness of devices. For example, we are often blinded by success stories and stick to hard-to-use devices because we have mastered them. In the chapter Reality, Thimbleby performs a tour d' horizon through a number of typical devices and presents examples of bad design. He demonstrates that even light switches can pose puzzling design and usage problems. In the final chapter of part I, Thimbleby makes the"transition to interaction programming." He takes a look at the field of HCI, criticizes its current overemphasis of user-centered design, and finally introduces the JavaScript the programming language, which he uses in the second part of the book in his programming examples.

Part II: Principles

The second and main part of the book teaches, as Thimbleby puts it, the "basic principles of interaction programming." First, however, he looks back at communication issues and codes, ultimately to support the argument that programming principles and appropriate algorithms can improve existing user interface designs. In the chapter States and Actions, Thimbleby introduces the four key concepts in interaction programming and the basic ingredients of finite state machines (FSMs): actions, states, indicators, and modes. Thimbleby explains: "The user performs actions, which change the device state, which in turn control indicators." Then he shows how to draw state machines and how drawing rules pave the way to interaction laws, such as "don't be rude" or "don't be misleading." Thimbleby also makes clear: "If you don't understand state machines, you don't understand interaction." I am not sure whether all interaction designers would wholeheartedly agree with his statement.

A major motivational factor for using finite state machines is that they enable designs to be checked and design quirks are found automatically. That is not only important for the design itself: it is also essential because even for fairly simple devices, state diagrams can soon become very large and messy. In addition, Thimbleby introduces state charts, which enable state machines to be drawn more easily and more clearly. These charts have a firm foundation because they are based on the Unified Modeling Language (UML). They are also not restricted to a graphical notation: the World Wide Web Consortium (W3C) has proposed a text-based XML notation for state charts. One reason why state charts are simpler is that they consist of clusters of states instead of single states. These clusters lead to a common, consistent action for all included states, and are thus essentially modes. Modes are relevant from a design perspective because users are unaware of internal states of a device, but often have an understanding of modes. For example, when a user presses the Setup button, the device is in the "setup" mode, in which certain operations are not allowed.

Pursuing his quest for an automatic analysis of devices, Thimbleby turns to graphs. He demonstrates that graphs can be used to represent interactive devices and graph theory allows for an analysis of their usability characteristics. For example, it is possible to search for the shortest path in a graph to find interactions with the minimal number of button presses.

At this stage, Thimbleby has put together all the pieces that he needs to introduce a basic framework for design, using the JavaScript language that he has introduced in Part 1: Context. He demonstrates how finite state machines can be programmed, prototyped, checked, and analyzed. First, Thimbleby uses it for building, testing, and analyzing simple interactive devices, and then he applies it also to more complex ones. Thimbleby points out that the use of the JavaScript language is not a limitation. His programming examples can be easily modified for use with Java or any other C-like programming language. I should also add that the framework supports the automatic creation and maintenance of documentation.

Part III: Press On

Part III: Press On applies the book's concepts to the "real world." First, Thimbleby asks: "How we can keep the simplicity of finite state machine, but change our approach so that successful real world, complex designs can be undertaken, too?" The real world is complex – that's a fact – and "the issue is ... to avoid unmanageable complexity." It leads to design errors and flaws that should be avoided, from both the users' and the designers' (who have to fight with bad legacy designs) points of view. Thimbleby lists a dozen heuristic methods that can help avoid design flaws and discusses each of them thoroughly. One heuristic approach, for example, says: Make the device behave like the real world. Here, symmetry, a common characteristic of objects in the real world, is a key principle. Thimbleby is well aware of the fact that "good design is not just a matter of knowing ... theories and principles. It's also about understanding people ... and having the right attitudes. Therefore, in the chapter Improving Things he examines personal and ethical aspects of design, among others, usability and design as "applied ethics." Finally, in the last chapter, Thimbleby recapitulates his approach in four key principles of interaction programming:

Use good algorithms for better user interfaces – algorithms are structured ways of solving problems
Use simple, explicit interaction frameworks – with a clear structure, features can be integrated reliably, checked, and analyzed, and faults can be identified and fixed
Interrelate all interaction programming – use tools that manage the design
Define properties and analyze designs for them – defined properties allow designs to be compared and improved

Discussion

At the end of this already lengthy review, I would like to focus on three issues: (1) the role of user-centered design, (2) the use of finite state machines for design, and (3) the usefulness of the book for UI professionals who are not students of computer science and do not design interactive devices.

The Role of User-Centered Design

Thimbleby comments on user-centered design (UCD), in particular the way it is overemphasized in comparison with engineering and computer science, at several points in the book. He criticizes the prevailing perspective, which could be paraphrased as "Center design on the user and then just tell the programmer what to do," or: "Programmers don't know how to design, so human factors experts, usability experts, or psychologists must lead design." Thimbleby's point of view is: "It's truth, but not the whole truth." In his opinion, this overemphasis "misses a few points" and may lead to nice-looking but technically questionable systems. He also criticizes UCD as promoting a sequential design approach instead of an iterative one, thus preventing concurrent design. The latter criticism is largely outdated. However, I would agree that there is some competition or even animosity between the more technically-oriented and the more user-oriented fractions in the design field. I would also agree that asking and observing users is not the whole story. If HCI is ever to become a true engineering discipline (or an applied science), we need fundamental principles – whether they are derived from practice or science – on which we can base solid design decisions. Otherwise, design can become just a random walk, depending on which and how many users we ask – as Rolf Molich showed in several investigations.

The Use of Finite State Machines for Design

Thimbleby promotes the use of finite state machines, but these machines have also been criticized for, for example, being finite, large, and unstructured. Thimbleby offers responses to a number of these arguments. One common argument is that in practice "few systems are implemented as finite state machines" for a number of reasons. Most designers prefer to develop in an ad hoc manner, which is often "justified" by tight time schedules. Thimbleby argues that, in the end, this approach leads to unmanageable and unusable systems – our daily reality.

I assume that there is a difference between designers who regularly implement devices such as remote controls and designers of software applications. I have never seen anyone in my company using finite state machines to design software applications, even though Thimbleby shows that this is at least a viable option for Websites. He appeals to designers to "use simple techniques as long as possible," such as finite state machines, and, in addition, to "use sophisticated design tools." This combination offers definite advantages: The first encourages the design of simpler systems, and the latter enables design properties to be automatically checked and analyzed and user manuals and other materials from the machine's specifications to be automatically generated. All in all, we have once again come across the difference between theory and practice, not to mention the issue that designers often are not free to choose their tools.

The Usefulness of the Book for UI Professionals Who Are not Students of Computer Science and Do Not Design Interactive Devices

At the end of my review, I would like to point out that this review is not an objective assessment of the book. It should rather be viewed as a comment from someone who is a member of the UI community, but does not belong to the target audience. In fact, I am a member of the user experience team at a large software company. As far as I know, only some of my colleagues have an education in computer science and are trained in formalisms. And even though my colleagues might be interested in learning about the concepts explained in this book, only a few of them will ever find the time to read the book from start to finish, do the exercises, and perform the exercises on their own – with exercises being a very important aspect for Thimbleby. This raises the question of whether it is worthwhile for my colleagues and other non-target audience members to read the book. In short, my somewhat frank recommendation is: Eat the bread and scan the meat (or salad). Of course, you can stop anywhere in the middle section of the book and dig deeper. I found the first three chapters and part III in particular offered so many enlightening ideas that I have recommended the book to anyone who is active in the UI design field, be it building interactive devices or designing software applications and Websites. By the way, my favorite chapters in the book are "Computers as consumer products," "Externalizing use cost," and "The productivity paradox." These chapters were real eye openers – as was Thimbleby's observation that computers encourage us to make our society more and more complex. Once I had grasped this, I found more and more evidence for it.

Conclusion

All in all, I recommend Press On to everyone who is active in the UI design field, even though only about 40% of the book may be relevant to them. This 40% offers a new understanding of the field. Of course, it would be very unfair to suggests to Thimbleby that he should publish the bread without the filling and name it, for example, The Interaction Design of Everyday Things (I know that Thimbleby would prefer programming instead of design). This book is definitely worthy of a place next to Don Norman's The Psychology/Design of Everyday Things on my book shelf.

top