Preface

The primary goal of this book is to help the reader create multimedia projects in Squeak. The book helps with other goals, too, but the reader-as-student is the primary audience here. "Student" will get swapped for "reader" in many places. The structure of this book is aimed at the undergraduate computer science student, though the content is more generally on multimedia projects in Squeak.

Whatever brings you to this book, the assumption is that you're trying to do projects, serious efforts requiring pages of code. This book provides the information needed to get going with objects, user interface, and multimedia in Squeak. The assumption is that you are using Squeak, and that you're actively trying to figure things out. This book gives you the tools to do that.

However, this book is not a reference to Squeak, in part because such a thing (on paper, at least) would be impossible, as suggested by Alan Kay in his foreword. Furthermore, the tools are in Squeak to serve as a form of dynamic reference (as seen in the Tools and Strategies sections of the book). But most importantly, making this book a reference would be a different task from the one I set out with: To create a tool for learning through Squeak projects.

This book was started in Squeak 2.5; at the time of this writing, Squeak Central was about to release Squeak 2.8. Most of the examples will work with all these versions of Squeak, but they are all tested against Squeak 2.7, and that's the version that is recommended for use with this book. APPROACH OF THE BOOK

When many American universities were established in the late 1800s (e.g., Stanford, the University of Chicago, and others), they were designed to be a mixture of the English college, with its focus on undergraduate education, and the German university, with its focus on research. The goal was for the research to motivate, and even inspire, both students and faculty to be better learners and teachers. While this works in the best cases, it has most often led to a higher priority on research than on teaching. (For a fascinating analysis of this tension, see Larry Cuban's How the Scholar Trumped the Teacher, Columbia Teacher's Press, 1999.)

The approach of this book is to be the reverse—hopefully, closer to the aims of the original inventors of the American university system. The book aims to integrate the diverse areas of knowledge needed to create successful projects. The pedagogy of this book is based on research in the learning sciences, on how people learn. The content of this book is based on my research, and that of my students, in developing collaborative multimedia in Squeak. The case studies in the latter half of the book are real projects that we designed, implemented, and then evaluated with real users to test the usability and effectiveness of our software.

The structure and approach of the book may be uncomfortable to some. It may even seem intuitively wrong to some. Intuition can sometimes be a dangerous thing—science has shown that measurement sometimes leads to findings that are contrary to "common sense." Science has come up with many ideas that seemed intuitively wrong, like disease being caused by small things too small to be seen by the naked eye, and that all objects fall at the same rate. As the methods of science have been applied to learning, similar non-intuitive lessons have been learned.

I attempted to apply the lessons about learning to the design of this book. I recognize, though, that research's lessons are not obvious—they require interpretation. My interpretations may be controversial, and even outright wrong. The responsibility for these interpretations is my own, not the original researchers'. Start from Where the Students Are

There is a school of thought that says that students should be taught the abstractions necessary for proper execution in a domain before they are taught the actual execution. The argument is that the students' minds are then prepared to learn the "right" way to do things. This argument has been used to push for theory ahead of practice, design before implementation, and learning algorithms and development methodologies before actually doing any programming.

One of the unfortunate realities of our cognitive system is that we're very bad at transferring knowledge from one domain to another, even when the two domains are tightly connected. We've known since the 1920s that students develop "brittle knowledge" (Alfred North Whitehead) that can be applied for a given exam or given course, but that seems to disappear outside of the original class. The formal study of "brittle knowledge" arguably began in mathematics education research, where students were found to become experts at one kind of equation, but were totally confused by the addition of a single extra term. The phenomenon was also noted in physics students, who could get A's with their tight explanations of acceleration and energy in a thrown ball, but who would explain outside of class that a ball falls because the atmosphere pushes on it. In my own research, I've been amazed to find that engineering students seem to forget almost all of their Calculus when they get to the junior and senior years.

If students do not see the connections between areas of knowledge, then they won't transfer the knowledge. If they do not understand what they're learning, they can't see the connections. But if students do understand material, if they can see lots of relations between what they're learning and what they've known before, the knowledge is more likely to transfer to other disciplines and to be retained longer.

Case-based reasoning, one theory for how our cognitive systems work, has an explanation for all of this. As information comes into a mind, it becomes indexed. When a new event appears, the mind uses its indices to figure out if it's ever seen anything like this before. If it has, then a connection is made. If our indices are developed well, we can match things as being similar. But if we learn things with indices that say "This is a fact for a specific course," as opposed to "This relates to design of programs," then we don't apply the information appropriately. It is possible to reindex things later, and it is possible to learn abstract things with appropriate indices, but it's easier to learn new things as variations of known things, and then extend the indexing schemes.

The goal of connecting to what students already know is to meet the students where they are. While a student can memorize and even learn to reason with abstract material, this is a sign of the intellectual capabilities of the student, not the usefulness of the material. The real test is whether the students can use the knowledge later. The odds of having usable knowledge are improved if the material is presented when it makes sense to students and can easily be related to knowledge that the students already have.

Academics, researchers, and other smart people often disbelieve this point. They reflect on their own learning and note that they often prefer to get the abstractions first. There are several responses to this kind of reaction. First, self-introspection is not necessarily the best way to come up with lessons about learning. People do fool themselves. (For example, people often believe that shortcut keys are faster than menus, but all explicit laboratory measurements show that mousing over menus is always faster—see Bruce Tognazzini's Tog on Interface, 1992, Addison-Wesley, for a review of this research.) But perhaps the more significant response is that smart people are already smart. They've picked up all kinds of concrete and abstract knowledge already. They're excellent learners who know how to figure out connections to new knowledge. As my advisor, Elliot Soloway, likes to say, "20% of the people will learn whatever you do to them. It's the other 80% that you have to worry about."

For these reasons, the order of events in this book is concrete and easily understandable first, and abstract and more general later:

Squeak is first introduced as being like other languages that students might know, and then the new and original features are introduced. Two chapters on Squeak programming appear before the chapter on design of object-oriented programs. Technical details of building user interfaces are presented before interface design principles. Learning involves Testing and Failure

Noted cognitive scientist Roger Schank has promoted the importance of "failure-based learning." If you're always successful, you don't learn much. But after you've failed, you're in the perfect position to learn a lot. Someone who has just failed is now interested in reading, in exploring theory, and in engaging in inquiry in order to understand the failure and how to avoid it next time. In order to fail, you must face a "test" of some kind. The test doesn't have to be of the paper-and-pencil type. It doesn't have to be formal at all. But if there isn't an event that tests your knowledge and provides the opportunity to fail, then the failing and the learning will never occur.

Computer scientists are well familiar with this process of testing, failing, and learning from the failure. We even have invented a nice word for it: debugging. Debugging is such an important part of computer science that computer scientist and educator Gerald Sussman has been quoted as saying, "Programming is debugging a blank sheet of paper."

But when it comes to user interfaces, computer scientists tend to shy away from a real test. The buttons get pushed, and the menus get dragged, and success is declared. However, the design of the user interface should be based on what the user wants, not whether the buttons can be pushed. To really test the design, one has to face the users. This is called user-interface evaluation.

Students cannot learn design without evaluation. Otherwise, it's almost impossible for the design to fail, and thus learning cannot occur. The evaluation does not have to be very sophisticated. The "discount usability methods" of Jakob Nielsen and others work because the real problems of user interface design tend to be right up front and pretty easy to see.

The chapter on user-interface design includes sections on evaluation. But more importantly, each of the case studies in the back of the book includes an evaluation with real users. Some of the evaluations are survey-based, others are observational with interviews, and still others use recordings of user events to figure out what happened. In every case, there is some testing of the design assumptions. Generation and inquiry, not Transmission

Even though people speak of "transmitting" or "delivering" material in a classroom, that isn't how learning works. Cognitive science has known for decades now that all real learning is constructivist: It's an active process of figuring things out and relating them to other knowledge. The goal of education is to motivate students to think about things, and thus learn.

The goal of a book, then, is not to deliver facts, but to provide methods of generating knowledge and fuel for students' inquiry. A list of phrases to be memorized doesn't lead to learning. But if a book explains how to do something, and then provides some interesting somethings to do, then the setting for learning is prepared.

There are sections of this book explicitly labeled Tools and Strategies that are meant to show how to dig into Squeak, how to study the exercises, and how to build your own things in Squeak. The rest of the book is meant to fuel inquiry, that is, students' exploration of things of interest. Inquiry can take lots of forms in lots of different directions. The goal of this book is to provide starting places for many of these: From a historical or technical perspective; from object-oriented design or user interface design; from building objects to building interfaces. CONTENT OF THE BOOK

This is a book about using Squeak to build multimedia programs. It is not a general book about object-oriented design, interface design, or multimedia design. Rather, it's meant to be a book about using a particular programming language (that has a rich history and is particularly well suited for use in computer science education) to build projects that cross diverse areas of knowledge. In order to build multimedia programs in Squeak, students need to know the following things:

How to program in Squeak, from both a language and an environment perspective; How to design programs for Squeak; How to build user interfaces in Squeak; How to design and evaluate user interfaces in Squeak; How to do multimedia in Squeak; Four detailed examples that describe how to do all of the above, with a particular emphasis on design and evaluation.

In short, that's the content of the book.

Readers who aren't interested in all six of these topics may want to take one of these other paths:

If you already know Smalltalk and want to learn Squeak: Chapter 2 is an overview of Squeak, Chapter 5 (especially Sections 5.3 and 5.4) introduces user interfaces in Squeak, and Chapter 7 discusses multimedia. The case studies will also all be useful. If you are focused on object-oriented design: Chapter 3 is the transition from the focus on programming (in Chapter 2) to object-oriented design. Chapter 4 is the main chapter on object-oriented design issues, though the case studies also present object-oriented designs and evaluations of those designs. If you are focused on HCI: Chapter 5 tells how to build user interfaces in Squeak, and Chapter 6 centers on how to design them. The case studies provide HCI evaluation examples.

The book is particularly aimed at the early-to-intermediate undergraduate student. There is an assumption here that students already know some programming language, but little else. The goal is to quickly get students producing multimedia applications in Squeak. It serves as an excellent lead-in to more advanced classes in any of these subject areas.

At Georgia Tech, we have been teaching a course on material like this for over five years. It has met with success, in terms of student performance and satisfaction with the content. This book is based on the notes for that course. I hope that this book will be as successful in other classes, and for you, the reader, however you come to this book. ACKNOWLEDGMENTS

This book builds on the efforts and contributions of many developers, reviewers, teachers, students, and colleagues. My listing their names here does not imply that the end product reflects their preferences, but they have been important influences for me in writing the book.

First of all, thanks to Squeak Central: Alan Kay, Dan Ingalls, Ted Kaehler, John Maloney, Andreas Raab, Scott Wallace, and Kim Rose (and Jeff Pierce, in his former intern role). The most obvious gratitude is for giving us Squeak, but I also owe them enormous thanks for the hours of help they have given me in answering questions, looking over sections of the book, helping me find resources, and so on. Thanks, especially, to Alan, for providing the thought-provoking foreword to the book.

Thanks to the Squeak community for answering questions and to many of them for explicitly reviewing and commenting on versions of these chapters. Special thanks to Stephane Ducasse (who gave an enormous amount of time and effort reviewing), Naala Brewer, Jennifer Brown, Piero Campanelli, Ward Cunningham, Marcus Denker, Andreas Dieberger, Steve Elkins, Dick Karpinski, Mayuresh Kathe, Patrick Milligan, Stefan Rieken, Mary Beth Rosson, Frank Sergeant, my colleague and coteacher Richard LeBlanc, and several anonymous reviewers. My thanks and admiration go to the teachers who first trialed this book in their classes and gave me some of the most valuable feedback I received: Rick Zaccone at Bucknell, Rik Smoody at Portland State University, and Cullen O'Neill at the University of Michigan.

Thanks to the many Squeak students at Georgia Institute of Technology's College of Computing who helped me learn how to teach Squeak and what difficulties people had in learning Squeak, especially to those students and teaching assistants in CS2340 who first trialed the book and gave me feedback on it. Some of the exercises here were based on labs invented by TAs Jennifer Brown, Anna Shleyfmari, and Ivan Brusic.At a risk of leaving out some of the Squeakers, I want to highlight the contributions of Ivan Brusic, Colleen Kehoe, Bolot Kerimbaev, Aibek Musaev, Bijan Parsia, Noel Rappin, Jochen Rich, Lex Spoon, Michael Terry, and Rodney Walker.

Alan Apt and Toni Holm of Prentice-Hall were amazingly patient and supportive of a first-time author, and I appreciate their help.

Thanks to Ivan Sutherland and Sun Microsystems for permission to use the picture of him running Sketchpad in Chapter 1.

Parts of the case studies (especially the Swiki or CoWeb) were developed with the support of the National Science Foundation as part of our work on collaborative learning environments.

Last, but not at all least, to my children Matthew, Katherine, and Jennifer and my ever-patient wife, Barbara, who gave me time to work at the book and had even more confidence than I that it would become finished one day. Thanks for your loving support!