The Macintosh at 20: Interview with Jef Raskin
Professor Jef Raskin
Creator, Apple Macintosh Computer
Author, The Humane Interface
2004 is indeed the 20th anniversary of the Apple Macintosh computer, but the history of this computer is actually a little older than this. Joining us is Jef Raskin (JR) who started the Apple Macintosh project. Frank Ling (FL) talks to him about how the project got started, his perspectives on current operating systems, and his current work.
FL: Perhaps we could start by talking about how this project was begun and your views on how the interface has evolved since then.
JR: When I was a graduate student in computer science at Penn State — because of my strong interests in the arts, music, and visual arts — I was assigned the task of helping people in the computer center, for people who were in the fine arts or the liberal arts, and they struggled trying to use the computer. Most of the other computer science grad students had the opinion that there were those people who got it and those people who just don’t get it. But once I observed them working, I realize it was not the people who were having the problem, it was the fact that the way our computer systems were designed that was giving them all the problems, and the reason why the people got it got it was because they spent a lot of time learning all the intracacies of how they work. And I realized that we should be designing computer systems to make them easier to use and that was more important than what I was being taught in my computer science classes, such as how to make programs run in minimal time or minimal space and how to do those trade-offs. All of that is interesting and valuable. I used that inflational time in designing systems, but it was the interface that was clearly most at fault.
FL: And this was during the ’60s right?
JR: Yeah, I graduated in ’67.
FL: I understand you did some work before you arrived at Apple on the graphical user interface. Maybe you can tell us a little about that.
JR: What I did write my thesis — over the objections of my thesis adviser — was that computers should be graphic from the get go. Those days, everything was all character generators and I said characters were just a special case of graphics and I wanted to do music notation, I wanted to do various languages and of course you could not do that on computers in those days. So, I had very firmly in my mind the idea of having a computer being bit-graphics based. I built my own graphic input device, which turns out to be the same year that Engelbart was developing the mouse. And that led to my wanting to design the Macintosh when I worked for Apple. At the time, Apple had the Apple II and was working on the Apple III, and even the original Lisa was a character generated machine, and I was proposing a graphics-based machine that I called Macintosh for my favorite kind of apple that grows on trees.
FL: A lot has been said written about Xerox Parc’s contribution to the user interface. Perhaps you can clarify this a little bit.
JR: Well, I was a visiting professor at Stanford at the Artificial Intelligence Labs in I guess starting in 1973 and there was sort of a floating population from the AI labs over to Xerox Parc, which started I believe in 1972, and when I went over to Xerox Parc, I found for the first time, I found a population of people who believed as I did that users, human beings, have to come first. What do we build computers for except to help people and it was like finding home. All these, whole groups, over there were interested in that. The contributions of Parc are very broad, very deep, many many brilliant things were done there and many of those things later were to appear in the Mac and other computers. But a lot of the ideas people said came from Xerox Parc had already, I had already thought of or actually implemented before there was even a Xerox Parc. So while there was a big strong intellectual debt to the work at Parc, it was not as though we came in and stole all their ideas. There is a legend that Steve Jobs at the end of 1979 went to Xerox Parc, saw the Alto, and said we’re going to come back and invent something called the Macintosh. It’s been widely reported that way, however, the fact is the Macintosh project was started months before he even went there.
FL: So, what about current operating systems. Do you have any comments on their interfaces?
JR: I’m very disappointed in the Macintosh interface. It’s more complex, harder to use than it was when we started. It’s always puzzling people. Even though I have the latest version, OS X, what they call Panther. The Panther keeps on biting me, crashes once or twice a week. The whole system crashes, individual programs crash pretty often still, but the interface is so complex, there’s so many parts to it that I have to go to other people and ask them how do you do this. Sometimes people come to me. Nobody can understand the whole thing. And of course you don’t get a manual with it. There’s no nice manual that leads you from the beginning: here’s what all these different things do and if you do this, you need to use this secret trick. For instance, when my machine behaves too badly, I have to know to restart it while holding down Command — I’m reading from a cheatsheet that I wrote for myself — Command-Option-O and F, and then at the prompt I type “reset hyphen n, v, r, a, m” and then I have to type on the next line “m, a, c hyphen b, o, o, t” and then things straighten out. Now, does that sound like a friendly interface?
FL: Sounds a bit complicated.
JR: It is. You’ve used machines. You’ve used Windows I’m sure and I’m sure that you run into lots of occasions where it did something weird. Or you are using Word, everything suddenly changes and you couldn’t figure out how in the world it got there or how to get back. Well, right now I can go back between my Windows machines and into my Macs, hardly having to think at all, they are so similar and they are both quite dreadful.
FL: What about speech recognition. Do you see it becoming part of the interface in the future?
JR: That’s sort of a red herring. Speech recognition is just another input device. The real question is what are you going to say and what’s the computer going to respond? What does it matter if you have speech recognition and you have to type it in if you have to know some secret combination of codes to say to get it to do what you want and if it does things you can’t figure out, how to get out of. Speech recognition is just another input device. So for certain applications — yes it makes them possible, you can be driving along and tell you car to start the windshield wipers without having to take your hands off the steering wheel — but it doesn’t really go to the heart of interfaces. It’s sort of a minor detail compared to the major problems that interfaces have.
It’s interesting that you brought it up because a lot of people do and say, “Oh good, speech interface, that will solve everything,” and then you go on to one of these speech response systems on the telephone, press three if you want this system to explode. Speech recognition, if used badly, just like anything else is going to be a nightmare. That’s what my current work is all about. How one could use knowledge about cognitive psychology to make interfaces a lot better.
FL: You wrote a book recently The Humane Interface discussing the interface between humans and computers. Let’s talk about this a little bit.
JR: Well, first of all, I’m really surprised by the book’s reception. Since it was published in 2000, it’s had four English printings, now available in nine languages: Korean, Japanese, Spanish, Russian, German, Dutch. What it does is that it looks at how we can understand interface design based on mostly quantitative things on how human beings work. There has been for over a century now a discipline called ergonomics, which is how we physically interact with machines. For example, you know that you can’t make a machine, you can’t operate a machine, if it requires you to pull a lever down with a force greater than your weight because that will pull you off the ground and the lever won’t move. And so ergonomics says you got to make things that fit people, that people can handle, that are within the strength and they find the strength of fingers, the strength of arms, the lengths of legs, all of which are absolutely valuable to the designer. Well, we can do a lot of that for the operations you have to do in using a computer, the mental operations. We can quantify them, some of them, and at the very least, we should make our computer interfaces in accord with what we know about about human abilities. Unfortunately, this hasn’t been done.
FL: And how do you propose we can solve this?
JR: Myself and volunteers and anyone who is listening to this and wants to volunteer can just put my name into Google and send me email. I have to mention that my name is spelled with one f, “J, e, f, r, a, s, k, i, n,” and we are building up an interface that is much easier to use, much easier to learn, and is much more productive than any current interface. We’ve built a number of these in the past and they’ve tested extremely well. It’s beginning to get exciting. Most recent thing that the group has done has made it cross-platform so that it can be run on Windows, Linux, and Macs.
FL: When the Macintosh first came out, it had one mouse button. And today, it only still has one mouse button. Many PCs, on the other hand, have two or three. How many buttons do you think a mouse should have now?
JR: Well, first of all it turns out, there is a recent study, done with over 6000 participants or subjects that showed that it was mouse use and not keyboard use that accounts for almost all of the repetitive stress injuries that people have when using computers that people have when using computers. The mouse in particular, graphic input devices are important when you are working in graphics. As for the one-button mouse, I’d observed at Xerox Parc which had a 3-button mouse, that people were very confused as to its use and when I was designing the software for the Macintosh, in designing the interface, I figured that if there was only one button, there would never be any question on what you have to press the number of ways of using a one-button mouse. I think this was probably a mistake, in fact there is an appendix in my book which discusses why I think this was a mistake and what I think I should have done. One of the reasons I made the mistake is that there is a certain school of industrial design dating back to the Bauhaus which says that designs have to be simple, uncluttered, and clean. In particular, don’t put writing on it except for brand names or logos. If we had had a multiple-button mouse with two keys, labeled something like “select” and “activate,” it would have been much easier to use, but the idea of putting writing on keys did not occur to anybody, including me. So if I was designing one today, it would have two buttons and they would be labeled. The labeling also the other good effect of forcing software designers to use them as labels otherwise it’s clear that they are being misused.
FL: So are these labels static or dynamic?
JR: Static. Dynamic labels are a pretty bad user interface mistake. I don’t know if that’s too long a conversation for here and now. My book goes into it at some length. It’s the same problem with adaptive menus. There have been attempts to make menus where the items that you use most often pop-up to the top, but the actual effect, which people hate, is that they go and look for the item where it used to be and say, “Oh no, it’s been changed,” and now they go find it and they have to unlearn whatever habits they’ve developed and this actually slows them down and also undermines the trust you have in a system. Label that can change on buttons — I worked on some aircraft cockpits where people proposed things like that — there are couple problems with that, you don’t know what the button does, if you go and reach it again habitually, it does the wrong thing because the name of the button has changed. Also, your finger is usually on the button and obscures the label just when you need it most. There’s a fundamental principle that we can only pay attention, conscious attention, to one thing at a time, and when a computer system demands that we attend to two things or more, then we tend to make mistakes. They are called mode errors and systems have to be designed to avoid that. This has been known a long time, but the word hasn’t gotten around to software designers or interface designers. They throw up their hands and say, “Oh, that’s not possible to do.” That’s only because cause they are not trying hard enough.
FL: But when someone is playing an organ, there’s several sets of keyboards they have to manipulate at the same time. Wouldn’t that be the same complexity we are dealing with?
JR: No, in fact I do play the pipe organ, been known to use two hands and two feet at the same time, and it takes immense amount of practice to be able to do that. What you do is that you’ve got to reduce most of it to habit. If they suddenly change the keyboard arrangements on an organ, any organist would go crazy, even if there were labels on the keys. My A-flats now turn to E-Flats and it’s a disaster.
FL: Sounds like a bad practical joke. Well, I got a question specifically about the file structure. The ones we use on our computers are based on trees or hierarchical structure, but there have been other proposals. How do you think these file directories should evolve?
JR: People tend to get lost in hierarchical tree structures, I’m sure it’s happened to you when you were trying to find a file on a computer. You couldn’t remember the filename, you go tracking down this tree and that tree. And there are better systems. It’s the kind of thing which one gets up to the blackboard or when out of the book. So, if listeners are interested, take a look at my website, take a look at my book where it goes into these matters. The question is not so much of one of what the file structure should be, but what mechanisms you have for finding what you want. One really stupid example is the filename. Whenever you create a file, you’re supposed give it a name so you can find it again. Now, this causes you two huge problems. The first is that when you’re putting it away, you don’t want to be bothered with having to think of something and of the sudden, now i’ve got to think of something that’s short enough to fit in for how many characters it is, 31 or some such number, and it has to be something months from now you’re going to remember when you go looking for it and that’s a hard thing to do. Usually name it with some dumb quick name cause you want to get on to something else which is why you quit doing that. Then six months later or six days later, when you want to go find it, you can’t remember the name. We know that filenames don’t work. Everybody finds it horrible to use. So, what’s the solution? The solution is pretty much what Google has done with the web: allows you to search anything inside or outside, you don’t have to know the name of a website or its url to find something with Google. You just type in some random content that you think might distinguish it everything else and more often than not, you find it quickly. Well, the file systems that I’ve designing for many years all work that way. Instead of just the short name attached to a file, everything is instantly findable by high speed searching.
FL: Great, I guess we are running a little bit out of time. Are there any last words you’d like to add about yourself, your work at Apple, or your current work?
JR: Well, I’m hoping to get some people excited about working on this project which is all open source, which is on a CEV system. And right now, computers, which are supposed to be our servant, are oppressing us. I know very well how to make them a lot more pleasant, lot more productive, a lot less confusing, a lot less intimidating, a lot friendlier in short. And I’m hoping that people will come and join the effort or at least take a look.
FL: Mr. Raskin, thanks for joining us today.
JR: Thank you for having me.