Chris Espinosa met Steve Jobs at Paul Terrell's Byte Shop while the former was installing an Apple I, and later became friends with Steve Wozniak, despite having been warned against the two by his teachers at Homestead High School (which Jobs and Wozniak had also attended). He became a regular at Homebrew Computing Club meetings, and was employee number 8 at Apple (Mike Scott wanted to be 7). He developed programs to show at demos of the machine, and ran public demos of the Apple II until 1978, when he graduated from high school at started his freshman year at the University of California, Berkeley.
At Berkeley, Espinosa met Andy Hertzfeld, and rewrote the Apple II user guide at the behest of Jef Raskin, Apple's publications manager. He returned to Apple full-time, and was director of documentation for the Macintosh project. He hired Caroline Rose, Carol Kaehler, and various others to write the technical documentation and user manuals for the Macintosh; he also hired Sandy Miranda to write the "Test Drive a Macintosh" script.
After working on the Macintosh project, Espinosa spent a number of years working in Apple's Marketing division, then worked on the Kalieda project. He is now manager of the Components and Scripting department.
The interview was conducted on 13 June 2000. The transcript was created and edited by Alex Pang, and reviewed by Chris Espinosa. [Please note: This transcript is an interim version, and has not been reviewed and approved by Chris Espinosa. A final version will be posted in the future.]
The original recording (a cassette tape) has been deposited with Stanford University Library's Department of Special Collections.
Pang: Let's being with your experience with user groups. You met Steve Wozniak at Homebrew Computing Club, and were involved in the San Francisco Apple Core. How did you get into that world, and what did you get out of it?
Espinosa: Basically, I was a student in Homestead High School between 1974 and 1978. In the summer '74, before my freshman year, I took a class in computers-- I took summer school before high school, that's how much of a nerd I was [Pang laughs]-- and the equipment we had at that time was HP minicomputers and dialup connections to HP minis using basic dialup connections to Tymshare using Tymshare BASIC. We did all of our programming on that. Our instructor was Steven Headley. He was an incredibly efficient scrounge of equipment from local companies, and managed to build a very very good computer facility, including some books. He himself had little knowledge of computers. What he did was turn kids loose in an information-rich environment, let them go to town, and had the graduates come back and teach, which was a very good plan.
Armed with relatively little knowledge, I basically taught myself BASIC programming, wrote some code on the local machines, and got very interested in the whole thing. But I was very frustrated that the only time I could play on computers was when I was at school, and when I was at school I had other classes to take.
Pang: Was Steve Headley the same teacher that Steve Wozniak had for electronics?
Espinosa: No, mathematics. He was a math teacher, math and computers. He had taught both Woz and Jobs.
Pang: It sounds like there were some interesting teachers at Homestead.
Espinosa: There were some excellent, excellent teachers there at that time. Some of whom are still there. I had been taught by many of the same teachers who taught Woz and Jobs just a few years earlier, and those teachers warned me against them.
My electronics teacher was ex-military, and told stories about his experiences in the military and in business over and over again; so the class wasn't just electronics, it was industrial education, it was how to be a member of a work force. But it was how to be a member of the old work force: how to work for a company like Raytheon and Fairchild. Steve Headley's was basically the first New Economy class: it was, you're on your own, you're inventing something new, there are no rules, I don't know anything, do what you want, and if you do something cool I'll give you a good grade. The two courses-- the electronics and the computer science courses-- were diametrically opposite. I got value from both of them.
One of the chief values from the electronics course was that you had to document your projects: you had to write about what you were doing. The teacher told stories over and over again about how when he got into business for the first time, and he wrote memos, he would have to run his memos by his boss-- imagine this in this age of e-mail-- who would edit them with a red pencil and send them back, and he had to go through 6 or 7 iterations of that before he could send it out to its recipient. And that kind of discipline does not exist in the New Economy, which is really sort of sad, because people have forgotten how to write. It's not just spelling and orthography; people have forgotten how to compose decent sentences, paragraphs that have a point, and entire memoranda that serve a purpose. People just ramble in e-mail. In the Old Economy's discipline of business, communications are official, and must be clear, pertinent, and to the point. So it's sad.
But I got a very good education from the two of them put together, even through I don't think that they would have agreed on anything, and certainly didn't like or respect each other's teaching methods. But taking both classes was a real education.
In the summer of 1975, one of my friends and co-hobbyists had a father who was head of IS at Kaiser Aerospace and Electronics, and he had a couple tickets to the California Computer Show, which was being held in Rickey's Hyatt. This friend of mine and I went with his father to the show. We walked the aisles and there were these big disk drives, and minicomputers, and it was basically mid-1970s mini-mainframe oriented.
But there was one guy in a 5 x 5 booth with a card table, and an ASR-33 teletype tape punch, which we were very familiar with. There were no other ASR-33 teletypes on the floor, it was completely ancient, and he was trying to bootstrap it to a MITS Altair 8088 with Microsoft BASIC read from a tape punch. Even though we'd never seen an Altair, and we'd never seen Microsoft BASIC, we sort of knew how to do it. So my friend and I got the machine up and running.
The guy introduced himself as Paul Terrell, and handed us some flyers about his store, the Byte Shop, that was having its grand opening next month in Mountain View. So the next month we go up to Mountain View for the big grand opening-- and it's not open yet. He's still putting plaster on the walls, moving stuff around [Pang laughs], but my friend and I spend much of that summer at that and the other Byte Shops. At those computer stores, which was the early nexus where people would meet and share information, we read Byte Magazine and Interface Age, and saw flyers for Homebrew Computer Club.
The problem was that my friend and I were 13 and 14 years old, couldn't drive, and didn't really have the persuasive powers to get our parents to drive us on an evening up to Stanford Linear Accelerator Center.
But in one of the stores, I think the Palo Alto store, I met Steve Jobs when he was installing an Apple I. I started working on an Apple I because it had an incredibly advanced user interface: instead of toggling in your programs in binary on the LED panel, you got to type them in in hexadecimal in the keyboard [Pang laughs]. That was an advanced user interface. And it was a completely self-contained, one-piece design with everything on one board that you didn't even have to solder together yourself.
So I really became enamored of the Apple I, despite my friend's prescient observations that if I didn't learn 8088 assembler language and went with the 6502 I'd be stuck in a backwater, because the Intel chip and the S-100 Bus and Microsoft BASIC were absolutely going to be the standards. [Pang laughs] This was in 1975. And 25 years later, S-100 bus came and went, but Intel and Microsoft basically won, and I've stuck with the loyal opposition.
Pang: What's happened to this friend of yours?
Espinosa: Jim Guard, last I heard of him he was working at-- not Mountain Computer, not Cromemco, but one of the other S-100 computers that went CP/M and then morphed into something else. I have no idea if they still exist any more. I haven't heard from him in 20 years.
So I met Steve Jobs, and from that I was really encouraged to go to the Homebrew Computer Club. I think I got my mom to drive. She'd sit in the back, reading, while all of these slightly dirty and dangerous people discussed things that she-- She wasn't alien to all this, she was head of single student housing at Stanford, so she knew the neighborhood. She had worked with the Computer Science Department to put together the program that ran the housing draw, so she knew from computers. In subsequent years she would be a sales representative and then trainer rep for Lanier word processors, and eventually from that would be hired at Apple to run training for our word processor program. She worked at Apple for ten years.
So I sat in the back with the one person I knew, Steve Jobs, and he introduced me to Steve Wozniak and this other person I had seen from high school, Randy Wigginton. Randy lived in the area, and had gone to summer school at my high school, but during the year went to Bellarmine Prep. I didn't take classes with him, but I knew him from summers at Homestead. So there was a smallish community of people from Apple who sat in the back of the room.
The SLAC auditorium was really set up geographically, and people would go to the same places. The two back rows, in the center, were Apple; Jim Warren was always five or six down from the back, on the left hand side. The processor technology people were down on the right. Lee Felsenstein was on the stage; the Homebrew librarian, Bob French, was always front and center. Then there were various other cliques, and Marty Spergel kind of moved around. But it was like a high school cafeteria: you sat with the "right people." It was very amusing. During the Random Access section of the meeting there was a lot more mixing, but in the mapping section, you really knew where to sit, unless you were new, in which case you migrated around.
Homebrew was unlike any other computer group on the planet that has ever been. It was a unique experience: very bright individuals, a unique and unrepeatable structure, and much more of an investment in diversity than focusing in a single technology. They were all over the place.
I got involved with Apple, I started working with Steve and Steve in 1976, and when the company formed in 1977 I was one of the first employees. I worked there after school through high school. I wrote some of the early technical documentation for some products-- ApplePlot, the graphics tablet. I wrote some software, but not much.
I was working for Jef Raskin, who with Brian Howard wrote the original Integer BASIC manual, when I went off to Berkeley in 1978. When I left, Jef gave me a task. He wanted to keep me on staff, but knew that I wasn't going to be able to work the hours that I had been previously. So he gave me a long-term task: he gave me what Mike Scott had assembled as the mini-manual for the Apple II, which was basically the product of a series of nightly forays into people's desk drawers for anything typed-- or handwritten, in a few cases-- that smacked of technical material, that he periodically sent with Sherry Livingston down to the Quick Print place to print, collate and assemble, and put into binder covers with clear plastic and wraparound spine and three-hole punch
That was what was dropped in with every Apple II. That was the mini-manual. That was Apple's documentation. None of it was written consciously for an audience, and Jef said, "We need a technical manual for the Apple II." Actually, there was the mini-manual, and there was the "red book," which was essentially the same material in a red binding. Jef gave me a copy of the red book and said, "I want you to write a real manual out of this."
So I went to Berkeley with this charge, and worked 20-30 hours a week in my freshman year in college, and I came back at the end of the term with a 220 pages of camera-ready output from the Berkeley UNIX system. I had taught myself TROC [Chris: Not sure if this right], I had taught myself typesetting, I had written a 200+ page manual, and that was Apple's first published technical manual for the Apple II. I still don't know how I did it, and I managed to pass my classes, too. [Pang laughs] That year.
Pang: There's a story that appears in Malone's Infinite Loop, among other places, about you sleeping in the computer labs, and then in the park, while you were working on the manual. Your family was in the area. Why didn't you just go home?
Espinosa: Home was 60 miles away. I had been living in the dorms, and the dorms shut down. Why I didn't just get a hotel I don't know [Pang laughs], because Apple was paying me well enough I could have gotten a hotel room. But I was in total crunch mode. Anybody who's ever published a book knows that dealing with the last couple sets of final proofs is hard. And, because I was working in TROC, basically what I was doing was writing a great big computer program. So it was the juncture of doing final proof on a book, and finishing a computer program. I was literally working in the computer lab for 20 of the 24 hours of the day that they were open; when they shut the machines down for backup and maintenance between 2 and 6 in the morning, that's when I slept.
It just didn't make sense to go home: I was way too exhausted to get on my motorcycle and go home-- that would have been suicidal, doing 60 miles down Highway 17. Sometime I sneaked into and slept on couches in the dorm because I knew he wouldn't really kick me out, though he encouraged me not to do that on several occasions. Sometimes I just slept on benches in Strawberry Canyon, because it was only for a few hours: I'd go out in 2 in the morning, and as soon as the sun was up, the machines would be back up, and I'd go back to work. It was only for a week, but it was one of the most strenuous week's work of my life. I didn't really repeat that until shipping Macintosh.
So at Berkeley my faculty advisor for my first self-paced computer course in the first quarter of my freshman year was Andy Hertzfeld, who [Pang laughs] was a graduate student at Berkeley. He and Barney Stone had started a local Apple user group, and they had some relationships with Bruce Tognazzini and the Apple Core, over in San Francisco.
My first real encounters with user groups were not good. It was the mid- and late-1970s, and the leftover social rebellion of the 1960s that turned into a personal independence movement in the 1970s got conjoined with technology, with the result that there were some people who now sought personal independence through technology. A lot of the impetus for this came out of the Whole Earth Catalog and Stewart Brand's work. There were people thinking that if they could master personal computing technology, they could fight back against the Machine. And so while there were lawyers who just wanted to use them to automate their offices, a lot of people in the users' groups were really using personal computers as a tool against The Man. And at that point, people in user groups were-- well, a little odd, and a little antisocial, and didn't necessarily have good social or even ethical skills. That's a sweeping generalization, but you just found it in a lot of places. And so there were a lot of people had bad human interfaces.
In the summer of 1978-- before I went to school, and after we'd moved from the Good Earth building into Bandley One, and when I was working for Jef Raskin--we had a guy who was from a user group in Southern California, who drove his family up in a motor home to come visit the Mecca of Apple Computer. This guy, named--it must be in the books, because I made him famous--he was associated with a user group and computer store in Southern California. Several people I know ended working for him as programmers, and complained about broken promises, promises to pay for computer programs that they wrote and he sold and never compensated them for, and generally slimy things like that.
He came up to Apple in the summer of 1978; he parked the motor home in the middle of the parking lot in Bandley One, in the middle of a summer day, for six hours; and, with his family sitting inside and sweltering in the heat, he meticulously and ravenously copied every single cassette tape of Apple software that was on the premises. The first hour, he was a loyal user and a fan, and we thought we should give him some of our software; but by the sixth hour, when he wasn't only copying our software and using our time and equipment to do it, but was asking us for blank tapes-- it was just a little bit beyond the pale!
And so that sort of flavored my experience with user groups. Homebrew was much different, because it seemed professional. Homebrew seemed like it wasn't hobbyists, but it was really smart people who wanted to do something. It wasn't a fan club, and most of the user groups that I had experience with after that were sort of fan clubs. Apple Core was in many ways like a fan club. They had the basic characteristics of-- yes, they were there to teach other people about computers, which was a great social purpose, and it was a great place to share knowledge and get your questions answered.
It was also a great place to pick up copied software, which in many ways changed the dynamics of software distribution. With copying so rife, you had to either go copy-protected, in which case people said, "Ooh, he's copy-protected; we won't buy that software;" or you really had to supple added value-- a box, a manual, backup disks, telephone support, a whole package. So it really bifurcated the software industry into the packaged software industry and everything else, because everything else was going to get copied and distributed on user group software disks.
Apple Core was also a place to swap rumors, sometimes accurate, sometimes inaccurate, about what the company was doing next. Later on, when I was a marketing manager and spoke to user groups formally, I had to be very careful with them, because user groups wielded an immense amount of purchasing power through their rumor dissemination; and if word in the user groups was, "Don't by product X, because product Y is coming out at time Z and it's going to be better," sales would suffer. Everybody at that point was paranoid of the Obsorne syndrome. Adam Obsorne announced his even better computer before he had completed sales and gotten rid of inventory of his old one; and when the project was delayed, as projects inevitably are, he faced a little cash flow problem, because nobody would buy his old computers because he told them something better was coming along. And with the Apple III and follow-on products to the Apple II, and software products, and the many models of the Macintosh, we were very fearful of the same thing.
We had a very delicate relationship with user groups, in that we wanted them to get information from the source, but we didn't want them to spread information that would be detrimental to our sales. That was always a tough relationship to have with them. The fan club user groups love getting inside information, and having a scoop or a secret, and many of them didn't understand how that could be detrimental to the company that they were a fan club of.
So that was pretty much my relationship with user groups early on: Homebrew, Apple Core, which I went to only two or three meetings of, and a small Berkeley Apple user group-- not even a predecessor to BMUG--that Andy and Barney Stone and I put together. That pretty much broke apart when Andy got a job at Apple and moved south, and I kept working for Apple. One of the interesting things about using groups is that if knowledgeable people in the user groups get jobs with the company, they can really no longer go to the user groups, because you can't talk-- you can't share anything. So once I really started working at Apple and being in on new products, I couldn't spend much time at user group meetings.
Pang: How did you become interested in and start working on technical documentation? How did you start doing it for Apple?
Espinosa: I was always a writer. I was always able to write and write well. It was one of my chief talents in high school and college. If a class required an essay, and a lot of the grade was based on writing, I would get a good grade in that class; if it required actual knowledge of anything-- like calculus-- I really did poorly. But through elementary school, junior high school, and high school, I wrote very, very well. I enjoyed writing, I enjoyed reading, I enjoyed putting together good sentences, I enjoyed having people read what I wrote.
My first job working at Apple was doing testing of the Integer BASIC that went into the Apple II ROM, in December 1976. Then, I wrote some demonstration programs. Mainly what I was doing in 1977 was writing demo programs, and doing demonstrations. People had this misconception that Apple Computer, at 20863 Stevens Creek Boulevard, Suite 3-C, was a real company, and that they could come and be greeted by a receptionist, and a sales representative might talk to them, and there would be a showroom where they could see machines. Instead, they'd walk into something that was a cross between the Bronx Zoo and the New York Stock Exchange. It was just incredible activity all the time, with people-- customers, vendors, venture capitalists, engineers, Mike Markkula, Steve Jobs, Regis McKenna-- running around all the time, very few set schedules, no meeting rooms. It was basically one big space, with carpet on one half and linoleum on the other half. On the carpet were half a dozen desks, for Sales, Marketing, and Administration. On the linoleum half, there were six lab benches, and that was Engineering and Manufacturing.
So when people read about us in magazines, or got our product brochure, or saw our advertisement, and were in the area, they would come over. They would open the door, and say, "I'd like to see a demonstration of your product." And there was just no way that the full-time personnel could handle that. So my job through most of the school year was to run demo time, every Tuesday and Thursday afternoon at 3:30. It was at 3:30 because that's when I got out of class. Demo time consisted of me, running the machine through its paces on a table, for whoever happened to stop by.
So I wrote demos, I did demos. I was, and continue to be, an extremely mediocre computer programmer. I took computer science in college-- this was before C. I do code now, and I really, really enjoy it; but I've found that the way to get good products out the door is to hire people who are much, much better than me, because I'm very pedestrian in the way I write code. But I enjoyed-- and this is perverse-- I found that I enjoyed documenting my code more than I enjoyed writing it. I enjoyed explaining to other people how it works. One of the first pieces of documentation I wrote was an explication of how Steve Wozniak's "Breakout" game worked-- line by line, in BASIC. That later was part of the Red Manual. When we hired Jef Raskin, he saw what I had been writing in terms of demo programs, and my documentation, and he said, "This person should be writing documentation, not software!" So he set me on writing some of the documentation for some of the early software packages that went out in 1977 and 1978.
Basically, I taught myself computer documentation. I had read a lot of documentation, everything from high-level software documentation to chip manuals, so I knew for myself what was good and what wasn't good, and made up the rest as I went along. And then we had some very, very good people who were hired at Apple: Phyllis Cole, who ran the pubs department for a while, Carole Cook and Steve Chernicoff, who had formal training in technical writing and were my editors. A writer always learns more from his editor than from anyone else, and Chernicoff edited me viciously: I would get back entire pages that were more green than black. That was how I really learned to be a writer. Just seeing that if I write it better the first time, I don't have to revise it as often-- the old lesson I learned in high school.
That was really how I became a technical writer. From technical writing I moved into technical writing management, and managed the Macintosh group technical writing. I hired people, I worked for Mike Murray, who was the director or marketing for the Macintosh, and learned a lot about marketing. Then, in the big reorganization of 1986, I became a product marketing manger, and spent ten years in product marketing, until I moved back into engineering. So basically, I've done documentation, marketing, and engineering.
Pang: When you get started in documentation, Apple is still quite small place, and still managed pretty seat-of-the-pants--
Espinosa: If you had pants, yes. [Hands over Apple employee card]
Pang: Employee number 8. [Hands it back] Was there special status associated with being number 6, versus 9, versus 12--
Espinosa: The only status issues were the legendary-- and I cannot vouch for its accuracy-- 0, 1, 2 debate between Woz and Jobs. The reason I'm number 8 is that Mike Scott wanted number 8; everybody else just drew what they got. 1 and 2, or 0 and 1 with 2 missing, were Woz and Jobs; Mike Markkula was 3, Bill Fernandez was 4, Rod Holt was 5, Randy Wigginton was 6, Mike Scott was 7, I was 8, I think Dan Kottke was 9. I knew who the first ten were, in order, but no one really paid attention to it after that. Today, the single digit badge gets me status because all the other badges are five digits! [Pang laughs]
I remember that for a long time we had a great Marketing gadfly who was the voice of Apple-- he did great demos-- and he made a big deal of having badge number 36. So there was a time when it conferred some status, but it wasn't like New Hampshire license plates or anything [the subject of a New Yorker article that week].
Pang: I want to understand where documentation existed in the development process. My sense is that at much larger places like H-P, most documentation was on finished products, but at Apple you were more intimately involved in development.
Espinosa: From Apple's foundings to the Lisa and Macintosh project-- they had a different attitude, a different philosophy, on those projects that Apple II and Apple III-- documentation was the poor stepchild. Not as poor as testing, but documentation tended to be what you did after the fact. Programmers never had enough time to explain to a writer what they had done, so documentation was almost an effort in investigative journalism: you really had to get in an figure out for yourself what the thing, rather than just writing down what the programmers told you.
You always were stuck in this classic conundrum. You had to be in the box with the product. The product was going to be done immediately before it shipped, because they sent the disks to dupe as soon as the bits stopped quivering. But the manuals had 6-week lead time. So there's this problem in that you have to as a writer, write accurately about what the product is 6 weeks before it's complete. So there was always a history of addenda and errata which were mainly things that changed after the manual was put to bed.
Documentation was always pretty much a contentious process. Programmers didn't have time to talk to documentation people because they were too busy writing code. They often didn't want to have to explain how their code worked: sometimes they didn't know how it worked, or they were being asked painful questions about what they were about to do before they had figured it out. It's really irritating having to talk to a writer who has this deadline who needs to know how you're going to implement something when you haven't written a spec, you don't know how you're going to do it, and you've got four other things to do now.
And then of course there's the controversy over the engineers reading your work and disagreeing with your writing style, or the order in which you're presenting things. As the most seasoned professional technical writers got in with a more school-learned, pedagogical approach to how they should present information, or we're trying to structure this in a template, and the programmers say, "But my program doesn't fit in that template! You have to write my manual special!"
Being a technical writer had its problems. Often the information you needed didn't exist. When it did exist you had to find it out because nobody was going to tell you about it. What you were told was often lies, or fantasies. And when they reviewed your work, programmers would either disagree with your writing style, or took a personal dislike to what you were saying. Some engineers would review an entire manual, and only change grammar or word structure or spelling, and not make any factual corrections to it at all. That was extremely frustrating. Then, you were told that you had to be in the box, and be ready 6 weeks before the product; but you were functionally unimportant because the software is really what sells. Like I said before, this was at a time when manufacturers were trying to impute value to software through bulk. People didn't understand why they should pay $120 for a software program when the disk cost $2 to duplicate.
So the entire software industry was trying to add value to software through packaging, and having a thick book was one of the ways to do it. But on the other hand, they wanted to hold down the cost of good sold. So they didn't want you to write a thick book, they wanted a nice thin book. But they also didn't want to take the customer support calls. So they wanted you to write a thin, comprehensive book-- that's also on schedule. The box that writers were put into was really pretty small and pretty tight, and there was a high amount of tension.
Phyllis Cole and Carole Cook and Nellie Connors, who were the three publications managers I worked for, did a really, really excellent job of navigating the political waters of assigning writers to jobs, and matching writers to projects, and joining the political battle and saying to programmers, "You don't have a spec? [Slams table] You don't get a book. You write a spec before you write the code, and you will get a book in the box on schedule. But if you're just going to make up the code as you go along, we can't write the book to get in the box."
There were other times when the pubs manager had to take the fall. I had to do that once with the LaserWriter. It was an open secret that the LaserWriter driver was not ready when we introduced the LaserWriter in January 1985. It wasn't ready, and it wasn't going to be ready any time in the near future. But we had this shipping schedule, because we had to ship it at the Annual Meeting, and we had the "Lemmings" commercial, and we were introducing the Macintosh Office, and the file server just plain didn't exist; the only things we had were the network and the laser printer, and the laser printer had to ship, had to ship, had to ship. And we all knew that the software wasn't ready. But Bob Belleville couldn't stand up and say to Steve Jobs, "We have failed, the software isn't ready." So it was just a kind of agreed-upon conspiracy, and me and Debi and Mike Murray just looked at each other, and I stood up and said, "I'm sorry, my manuals aren't ready, we can't ship." And it was true. But the reason the manuals were late was that we didn't have ANYTHING TO WRITE ABOUT! [Pang laughs] So I took the fall for that, but it was part of the politics of the pub manager's job.
But the Macintosh-- I can't say a lot about Lisa; Nellie Connor did a very, very good job in putting together the Lisa group, which took a much more traditional approach to documentation. The Apple II documentation was very freewheeling: it was a loose and open writing style, very conversational, very chatty, and people really loved them. But with Lisa they were going for blue-haired secretaries, they were going for institutional sales, so they wanted a much more professional look. So they had professional page design, they got a lot better typesetting and layout, while all the Apple II manuals had been printed on a letter-quality printer with headings Lettrasetted in-- literally, rub-on type-- and that was our camera-ready copy.
Lisa manuals were professionally typeset, but there were complaints that they were obtuse, they were ponderous, they were too big, they didn't get to the point, they used too much technical language, and that was just one of many, many things about the Lisa project that Steve rebelled against. Basically, when Steve hired us to do the Mac, it was to do the anti-Lisa. There was a lot of pointing across the street and sniggling and laughing, and saying, "Don't be like those bozos over there," and their manuals took a lot of that abuse.
When Steve hired me to put together the Macintosh documentation suite, he gave me a couple watchwords that completely changed the approach we took. First of all, I was hired to run pubs on Macintosh when the Macintosh group was only 6 or 7 people. It was fairly remarkable to get the Publications department in so early in the project. That's because Steve knew I had a lot of work to do in planning and figuring out what to write about. It wasn't just, "Here's the product, write about it." The second thing was that he really wanted to capture a value that he had captured osmotically from what people really valued from the Apple II: that with properly designed software, the system teaches you how to use it itself. If the menu structure and the purpose of the application and the user interface are clear enough, you don't need manuals.
So he told me that my job as publications manager on Macintosh was to put myself out of a job, in that in the best of all possible worlds, my job wouldn't need to exist, because the software would teach itself. And that was a real good lesson that a lot of people have forgotten: that the chief aspect of good user interface design is that people should be able to walk up to a system on their own, and figure out how to use it without having to read a book, or even having to read a help system. A help system is often not much better than a book, except you can't look at it and the system at the same time because you don't have the screen real estate. So I started hiring a bunch of people. I was only 20 years old, but Steve was 24, so he didn't consider this that unusual.
There were two major groups I worked with that got the publications process on Macintosh incredibly connected with the project as a whole. The first was with the software team. That started by doing tech documentation, and getting ourselves familiar with and well-connected with the programmers, by writing documentation by which they could get other people to write programs sitting on their operating system. I think that really really helped, because it proved to Jerome Coonen (Macintosh's software engineering manager) and Andy Hertzfeld and Steve Capps and everybody could trust me because we wrote the technical manuals that let people use their system software. You can't just publish APIs and hope people will understand how to do it: you need the low-level technical documentation to explain it. And when they started seeing these programs coming in from third parties that really used their software right, that helped confirm that the publications group was an integral part of the software design process.
Caroline Rose was just fiendish about that. She was our technical documentation lead, and her relationship with Andy was really, really funny. She was doing what I was talking about before, which was asking him the tough questions about what he was going to do next that he hadn't thought about before. She really made his life difficult, and helped him design better software. She would sit there and say, "But I don't understand. Tell me again how you build a control?" And he'd go through it over and over again, until he finally came to the realization that, "You know, if it's this hard to understand, I didn't do it right." And he'd tell her to go away, and then he'd completely reinvent it overnight. The next day he'd say, "Okay, this is how you do it now," and she'd say, "Oh, that's much clearer; thank you for explaining it."
Well, he didn't explain it better, he completely redesigned it, because it was so hard to explain. That is when documentation really works. And Caroline is the best I've ever seen at that. She sits in an engineer's office, and she-- she doesn't play stupid, she just asks them over and over and over again, to explain clearly what they mean. And it forces them to think clearly about what they're designing. She's just without peer.
But then I brought in my user documentation people. Lynnea Johnson did with Randy Wigginton on MacWrite what Caroline did with Andy and Steve Capps on the operating system. Lynnea had little if any formal experience as a technical writer, and she had little if any formal experience with computers. She didn't have very much experience working in business at all. She was working in the typing pool at Bechtel when I hired her. She had just come off of a three-year boat trip where she was part of a crew with rotating captainship; the ship just went around the world two or three times, and picked up cargo in one port and carried it to another, and that's how they got enough money to sustain themselves.
Those were her credentials to be a technical writer. I saw a writing sample and thought she had the right voice. I wasn't looking for-- in hiring for the Macintosh project we weren't looking for credential and experience, we were looking for people who were a good fit, and who got it. And she had the right writing voice, and she got it. And she just sat down with Randy Wigginton, and while trying to write about the user interface design of the rulers she'd say, "I can't explain this, it doesn't make sense." And then she and Randy would work out, well, what if you dragged the tab from over here, and it did this [motions with hands, as if dragging tabs].
So in those kinds of cases, the writing team that I hired and threw in with the programmers were really, really vital in designing the user interface. By being the people who had to explain it, they helped the programmers figure out how much better to do their work.
The anti-case of that were the interesting interactions between Bill Atkinson and Carol Kaehler. Carol had been in various places before. She'd done some technical writing at Xerox PARC, and she knew Bruce Horn from there. Her husband was Ted Kaehler, who worked with Alan Kay. She was writing the MacPaint manual, and Bill Atkinson had a different idea of how the MacPaint manual should be written. The other group I was working with-- and this fits in with the story-- was the creative services team. We had an incredible creative services team. It was first under James Farris and Tom Suiter-- he was the "S" in CKS Partners (profiled in Wired), and is now Chief Creative Officer of marchFIRST-- and then we hired our head of creative services for the Mac, and he put together a team under Clement Mok, who also later went on to do bigger and better things.
Steve's original idea for the manuals was that they would be like magazines. They'd be really readable, they'd be short articles, they'd be essays and things like that. The problem was that he didn't have a product to write about, and he we had all these traditional things we had to cover, like how to handle a floppy disk. So we worked and worked and worked with the graphic designers to come up with a book design that would both aesthetically and structurally serve our purposes-- what the typeface would be like, how the columns would be laid out.
We separated the book into three sections. First there was the tutorial, which would take you step-by-step through an introduction to the product so you'd get a feel for what it's about. The middle section was a cookbook, where each two-page spread, magazine-like, would be about a single task, like how to change margins, or how to copy a disk. It was originally designed with six columns, with substeps in the columns-- the idea being, you'd open to the page, put the page on the desk, and without having to flip through the pages you'd follow the steps and you'd be done. The third section would be a more traditional reference section where we just kind of walked through the product, menu by menu, function by function, and would explain what everything looked like and everything did. There would be callouts on the side with a handy tip, or something you may need to know, or here's a warning.
It was somewhat derivative of the book design for Lisa and Apple II, though the cookbook section was novel, and the writing style was a lot chattier. We also got to spend a lot more money on photography and printing on our technical manuals, because-- well, we worked for Steve. The expensive one was six-color process throughout. For the less expensive ones he demanded that we do black-and-white duotones, rather than just split screen for the photographs. It was lavish, it was very, very nice. Nobody ever got to spend that much money on manuals, but Steve wanted the whole effect to be crisp and professional and very high-quality.
So the process of actual writing went fairly smoothly. Once we had the structure, we put together the tutorial, and then we tested it: we ran people through the tutorial over and over again, and just watched people do it, and saw where people got it and where they botched it. That was a traditional technique and it worked very well. The cookbooks, the hard part was figuring out what tasks people would want to do, and then cramming it into the grid. The reference section was traditional. So we worked with the graphic artists to get the book design, and we worked with the programmers to get the content right.
The one outlier was Bill Atkinson, who thought that MacPaint needed to be different. Carol Kaehler had put together an alpha draft, a first draft, of the MacPaint manual, that was in our template: it had a longish tutorial, followed by a bunch of cookbook sections, and then it had a reference which led you through what the tools did, and what all the menu items were, step-by-step. Bill Atkinson thought that it was too big, too dry, too stupid, and too devoid of any kind of fun and exploration. We fought about it. I thought the books should be a suite, and they should have consistency, and continuity, and familiarity, and all the things we valued in the user interface. If you looked for a cookbook section in one manual, you should find a cookbook section in every manual; all of the great Macintosh values, that you should be consistent wherever possible, and maintain the graphic look.
But Bill's value was, MacPaint is different. And it was different: it took up the whole screen, you couldn't drag the window, you used the mouse in completely different ways. He, out of the goodness of his own heart, he and Susan Kare-- with a little help from Steve Capps and Rony Sebok and Andy Hertzfeld-- and not much discouragement from Jerome Coonen-- who knew how what they were doing would be received but just decided not to interfere-- one night when they should have been coding, stayed up all night and wrote a MacPaint manual that was the way they wanted it to be written. And they presented it to Carol with this look in their eyes saying, "We did this great thing for you: we saved you all this work by completely trashing everything you've spent the last 6 months on, and aren't you grateful for us helping you see the light on how your book should be written."
It was a challenging management moment. And because it was Bill Atkinson, after a couple long walks around the building and a couple of screaming fits with Steve, we just sat down and clenched our teeth and said, "Thank you, that's wonderful, we'll print just what you've written." And what came out what the MacPaint picture book. It delighted some and enraged others. And several years later, they wrote a real manual for MacPaint, because they had to. [Pang laughs]
So in the documentation process on Macintosh, we worked early and often with programmers, we started early on book design, and tried to keep a writing style that fit in with the whole character of the machine, and the character of the project as well: the sense of cohesiveness of the Macintosh team, and the fact that everybody got to work on and look at everybody else's process. Some of our best reviewers our books were people in Finance, who read our books voraciously. It was great having the Finance people review our books, and not for "This is going to cost too much to print," but "I don't understand how you do this in the word processor," because they were much more the target market than the programmers.
Pang: Some of the terms for pieces of the user interface changed between Lisa and Macintosh: what the Macintosh called the "scroll bar," the Lisa called the "elevator." Could you say a little about this?
Espinosa: There were tremendous debates about these terms. In Lisa, the colloquial term for the scroll bar was the "elevator," because it went up and down. The thing that you moved up and down was colloquially called "the thumb." We got off on this "metaphors should be consistent" jag. Even though people do not have windows and trash cans on their desktop, the idea of having a thumb in an elevator was a little-- [Pang laughs] So we decided to call those, a little more literally, a scroll bar and a scroll box. You could explain what they were and how they fit together. The elevator metaphor was useful, and the thumb metaphor was useful-- if you're going through a document, you thumb up, and thumb down. It was a Xerox term.
But the clash of metaphors-- People are remarkable at being able to keep a number of metaphoric systems in their head simultaneously. We studied this, some of us more than others. I went up to Berkeley and talked to George Lakoff about this. He was confused as to what I was talking about, he had no idea; I haven't talked to him since. Be was one of my college professors. But Metaphors We Live By, and every book of his that I read is absolutely astonishing. Most of the programmers I work with have Women, Fire, and Dangerous Things on their bookshelf. it's about categorization, and object-oriented programming is all about categorization. Programmers read linguistics; they really, really do. We read Metaphors We Live By, and it both gave us the determination to build things on a metaphoric system, and a little bit of freedom, knowing that people can keep multiple metaphoric systems in mind and mesh them without mixing them. If they're too intertwined, people get very confused.
So we wanted to keep to a small number of metaphoric systems that interrelated, but we didn't want to go as far as-- I think a good example of taking a metaphoric system too far is Microsoft Bob, where you have an entire environment that constrains what software can do to mimic real life in a metaphoric way, and impose artificial constraints to fit the metaphor. I think that's much less successful.