This is the story of how three sheets of lined yellow paper and three misfits spawned an industry.
The industry is desktop publishing, which today allows millions of ordinary persons to turn out newsletters, magazines, and books as though they were professionals; and allows millions of professionals—writers, editors, and publishers—to do their even more sophisticated work faster and easier.
The three sheets of yellow paper belonged to Butler Lampson. Covered with functions and algorithms written in his neat, angular hand, they represented his first pass at designing a text editor—a word processing program, if you will—for the Alto, which at that point did not have one.
The three misfits were Charles Simonyi, who one day happened upon Lampson’s scribbles and asked what they meant; and Larry Tesler and Tim Mott, who had been assigned to help Xerox’s textbook subsidiary find a way to make the editing and rewriting of manuscripts somewhat less tedious and time-consuming than the laying of bricks.
Together they achieved what Lampson later termed “one of the most successful collaborations in the history of PARC” (and that is a history rife with spectacular partnerships). The trio gave the Alto its “killer app”—the application that burned its unique virtues indelibly into people’s minds—as well as the program that first showed professionals outside PARC how the personal computer might improve their lives.
These programs were called Bravo and Gypsy. Their development consumed more than three years, starting with the moment when Simonyi reached out his hand for Lampson’s three yellow pages and said, “Can I take a look?”
With his mop of straight brown hair and his deep-set blue eyes, Simonyi might have stepped directly out of a Jacques-Louis David portrait of the young Napoleon. The similarity did not end there. Like Napoleon, Simonyi was a young man who rarely lacked the self-assurance to tell his elders where they were wrong and he was right. They also both came to prominence as outsiders: As Napoleon had come to the French revolutionary army from the rugged Mediterranean island of Corsica, Simonyi had crossed to the United States from the socialist hell of 1960s Hungary.
The elder son of a Budapest professor of electrical engineering, Simonyi had first encountered a computer at the age of fifteen. This was a Soviet-made contraption called the Ural II. The Ural was one of five computers in the whole country and a time machine of a unique variety. “All the action on this computer was directed through the console—it was truly a hands-on, one-on-one experience,” Simonyi recalled. “It was exactly like the personal computer of fifteen years later, because it was just you and the machine and no one else.”
The Ural could have been the model for the computer in every science fiction film of the 1950s and 1960s. The size of a large room, it was driven by thousands of vacuum tubes glowing with an eerie orange light. The operator’s console was like the keyboard of an old-fashioned cash register—six columns of numbered switches and an ENTER key on the right, all operated by a mechanism with substantial Soviet heft. “All this was very exhilarating because there was a lot of noise associated with it,” Simonyi recalled. “Every time I hit the switch it clicked very firmly. Whenever I cleared it, all the keys released at once with a great ‘Thunk!’”
Housed at a Budapest engineering institute, the Ural bedeviled its operators by blowing out at least one tube every time it was switched on. The only remedy was never to turn it off, which meant hiring someone to babysit the behemoth all night after everyone went home. Through his father, Simonyi wangled the job for himself. With the help of a mentor on the university faculty and the endless, empty nights available for full-time experimentation, he soon taught himself all there was to know about programming in Octal, the base-8 system on which the Ural was programmed. His first programs were designed to fill in “magic squares,” giant grids of numbers in which all the columns and rows add up to the same sum. Years later he could still remember how he would spend hours punching buttons on the machine to create magic squares eighty cells wide by eighty cells deep, then arrive home in the morning “with an incredible headache and giant rolls of paper printouts.”
After about a year a Danish computer technician he met at a Budapest trade fair offered him a job. Simonyi was sixteen. All that prevented him from leaving the country on a temporary pass was the Hungarian military’s craving for draftees. “The way I went around them was that I was underage, so they couldn’t draft me, and if you were in college you got a deferment. So I got myself admitted to the university and told them if you don’t let me go to Denmark I’ll go to university and you won’t get me. If you let me go, I’m coming back in one year, and then you’ll have me.”
Of course there was no question of his going back. This was 1966. Everywhere in Hungary memories of the aborted revolution of 1956 were still painfully fresh. “One thing that shocked me when I got to Denmark,” he recollected, “was that the houses didn’t have bullet holes in them.” Back home his father lost his job in retaliation for his son’s defection. “But he had a lot of political problems anyway, so this was just on top of it. Plus it was calculated in—either that I would have an unhappy life or he would have one more political problem. My parents agreed. My dad was practically pushing me to go.”
About a year and a half later Simonyi left Denmark for the United States. Because his situation at home was deemed not to have been perilous enough to warrant political status, he arrived on a student visa, which prohibited employment. “So I told the authorities that due to extraordinary circumstances I had to take up work. The extraordinary circumstances were that I was running out of money.” The job he found was at Berkeley Computer, where he encountered the troika of Thacker, Lampson, and Taylor and survived the one and only corporate bankruptcy of his life.
Following BCC’s collapse, Simonyi had tagged along with Mel Pirtle to his next job, which was to supervise the building of the Illiac IV on an ARPA contract at Ames Research Center, a NASA facility just south of Palo Alto. Illiac was a vast, overdesigned attempt at a large-scale system that some called the first supercomputer and others called computing’s Vietnam. (It never became fully functional, despite the expenditure of millions of dollars.) Simonyi tended toward the latter view, which is not to say he found the program entirely worthless. Aside from what it taught him about computer architecture, as a government program Illiac at one point saved him from being permanently evicted from the United States. This occurred when he left the country for a couple of days one January to visit West Germany—his first chance in seven or eight years to see his father, who was giving a lecture in Hamburg. In his excitement he overlooked not only his overcoat but the rule that once the holder of a student visa leaves the country he must reapply for permission to come back.
“So Friday evening at four o’clock I went to the embassy to say, ‘Hey, my plane’s leaving in one hour, would you please give me a visa.’ They took one look at me and said no. I called Pirtle right away and the wheels started to turn. They opened the embassy on Saturday, just to give me the visa stamp.”
Ever since his first labor-intensive experience with the Ural, Simonyi had been fascinated by the art of programming. By 1972, when he rejoined his BCC mates at PARC, he had come up with a less trying methodology, which he labeled “meta-programming” and made the topic of his Stanford doctoral thesis. Meta-programming involved a team leader’s drafting a detailed blueprint for a program using a highly abstract language, and handing this over to assistants for the actual coding of the software. The idea, as Simonyi described it with his characteristic bluntness, was to improve everybody’s productivity by giving the smartest programmer the freedom to think in broad strokes while a couple of overworked assistants reduced his ideas to code that the machine could understand. In essence, Simonyi was programming the programmers.
His first experiment in the process, which involved hiring two undergraduates from Stanford as these intellectual menials, he called Alpha. Around the time he was ready to conduct a second experiment, he found himself in Lampson’s office, studying the three canary-colored pages.
“What is this?” he asked.
“We need a text editor for the Alto,” Lampson replied. “Nobody’s working on it, so I thought I’d start.”
Lampson was being slightly disingenuous. The Alto did not just need a text editor—it needed everything. The machine had been around for nearly a year and, quite clearly, the novelty of Cookie Monster had begun to wear off. “Some people didn’t really see the potential of Alto,” Lampson recalled later. “We were trying to draw more people into it, because obviously the thing is useless without software. For the first year or so after it existed it wasn’t very interesting because it didn’t have very interesting software.” The yellow sheets were Lampson’s way of jump-starting the process.
Highly intrigued, Simonyi ran his eyes over Lampson’s formulas. He fancied himself a great programmer, which he was, having learned the art on one of the most recalcitrant computers ever built. But he was also aware, as he said later, that “it’s not enough to be a great programmer; you have to find a great problem.”
This looked like such a problem. Editing text on a graphical screen seemed easy at first glance, but it was rife with hidden difficulties and unexplored potential.
“I thought we were on the cusp of a paradigm shift,” he said later. “I could see books in their entirety flowing in front of you, virtual books and everything. In retrospect it seems so obvious. Uh-uh, it wasn’t obvious to anyone. This stuff was in the future then. But it was suddenly clear to me that with the combination of Xerox and this machine, word processing was going to be a key application. I took it and decided to make it happen, because it looked very sweet.” Since it would be the second experiment undertaken for his doctorate Simonyi moved one step down in the alphabet, and called it Bravo.
Beyond supplying his three yellow sheets, Lampson’s contribution to the making of Bravo exemplified his way of casting his influential net over dozens of PARC projects simultaneously. Having outlined the program’s basic building blocks for a like-minded collaborator, he let Simonyi do most of the heavy work, but stuck around to be his guide, mentor, and sounding board—as though implementing his own even more elevated form of meta-programming.
“What Butler contributed was the will,” Simonyi said later, “and what I contributed was that I agreed with him. I certainly discussed everything with him. I was the active person driving it and I drove it by asking him questions.”
Among Lampson’s fundamental ideas was a critical algorithm for holding an entire document efficiently in memory through the use of “piece tables.” These had been first developed by a programmer named Jay Moore. Instead of treating each letter or character in a text as an individual bit in memory, the piece table algorithm viewed a document as an arrangement of text blocks (or “pieces”). Inserting a sentence in the middle of a document converted the file from one piece to three—call them A, B, and C, corresponding to the insert and the blocks preceding and following it. These did not have to be contiguous in memory, as they were on the screen; it was only necessary for the computer to memorize a map—the piece table—that would allow it to find all the pieces in data storage and assemble them in the proper order for display or printing.
It is self-evidently easier to handle a document file divided into a few large pieces than one in which every character has to be manipulated individually, just as it is easier to carry a dozen eggs home in one box than to cradle them individually in one’s arms. The result was a tremendous savings in computing resources. Even if the writer wanted to do something drastic like transpose the end and beginning of the document, the pieces stayed where they were. Only the piece table changed, so the system would know that the pieces henceforth had to be read not as A-B-C, but as C-B-A.
Minimizing the movement of bits within memory allowed users to create more complex documents—as long as a piece would be stationary, why not make it heavier, so to speak? As he refined and enhanced Bravo, Simonyi figured out how to encode such characteristics as fancy typefaces, odd margins, and page numbers. Eventually he had Bravo polished to the point that it could reproduce a document on the Alto’s bitmapped screen almost exactly as it would appear printed out. The user could see displayed underlining, boldface, italics, and fonts of various styles and sizes—a capability that became known by the signature phrase of the comedian Flip Wilson’s sassy character Geraldine: “What You See Is What You Get,” or WYSIWYG, pronounced “wizzy-wig.”
Simonyi was right in predicting that nothing would underscore the Alto’s unique virtues like a powerful and flexible word processing program. Bravo was the all-purpose answer to the question of what a personal computer did: It magnified the productivity and creativity of every user.
“It was the killer app, no question,” Simonyi recalled. “People would come into PARC at night to write all kinds of stuff, sending letters, doing all personal correspondence, PTA reports, silly little newsletters, anything. If you went around and looked at what the Altos were doing, they were all in Bravo.” PARC personnel with access to the Altos found their popularity soaring on the outside. Friends writing Ph.D. theses would beg for permission to come in and type their work into the system. Then they would hit a button and get a gorgeously printed copy from the lasers.
But Bravo still had serious shortcomings. It looked every inch like a program written by engineers for engineers: The commands were complicated, difficult to learn, and prone to being misapplied. The marvels of WYSIWYG notwithstanding, the screen image appeared flat and uninviting to the ordinary user. Critics derided the display as little more than a “glass teletype” that failed to take advantage of the Alto’s brilliant graphical capabilities. If Bravo were truly to be embraced by users outside PARC and the confraternity of research scientists, it would need a more creative and accessible user interface, a screen format that would render the program and its daunting menu of commands and capabilities intelligible to the average person.
It was not by accident that Lampson and Simonyi had given the interface short shrift. They figured they would have their hands full getting the program to work, much less making it look pretty. “When we built Bravo,” Lampson recalled, “we made an explicit decision that we would not work on the user interface. We said, that’s going to be too hard and we don’t have the resources.”
Fortunately, down the hall in the Systems Science Lab the two other misfits of this story had been approaching the issue of text editing from the opposite direction. Larry Tesler and Tim Mott were deeply involved in the design of just such a user interface. What they did not have, but CSL now did, was a decent word processing program to hang it on.
Almost from the moment Larry Tesler joined PARC as a recruit from the Stanford Artificial Intelligence Lab, he felt out of place. His main job was to write software for POLOS, the “PARC On-Line Office System,” which was Bill English’s scheme to reengineer Doug Engelbart’s interactive multimedia system using the superior resources that Xerox money could buy. The work was being handled by a group of engineers English had raided from Engelbart, and they went at it with all the quasi-religious enthusiasm they had once felt working for the great man himself.
What made Tesler feel like a stranger was a rather fundamental disagreement he had with his colleagues: He thought POLOS was ridiculous.
Larry Tesler had never worked for Doug Engelbart. Not having partaken of the master’s heady wine, he was troubled by POLOS’s complexity. As imported from Engelbart’s lab, the system required users to learn a dizzying array of commands and key sequences involving the mouse, keyboard, and—especially frustrating—a bizarre device known as the “keyset.” This was a pad with five unlabeled levers, resembling the steno machines one saw in courtrooms. Pressing the keys in various combinations could give you any letter of the alphabet and a wide range of specialized commands—impressive enough as an engineering achievement. But Tesler could not imagine why anyone would want to use such an esoteric gadget.
Two other features of POLOS also offended him. The first was its time-sharing heritage. POLOS was based on the ancient principle that computers were so expensive they had to be shared. The system was designed as essentially a pool of Nova minicomputers linked by cable to video terminals in every office. A user logging in at any screen would automatically be assigned an idle Nova out of the pool, which would serve as his or her “personal” computer until the required task—typing a letter, parsing fields in a database, or performing an engineering study—was done. But no one would “own” an individual machine, nor would there be any guarantee that in periods of high demand one would not have to wait for a Nova to get free.
Tesler hated the very idea of sharing computing cycles, an emotion that dated from an incident that happened when he was a fifteen-year-old senior at New York City’s elite Bronx High School of Science. In short, he had gotten banished from a university computer center for throwing the wrong switch.
The year was 1960. Tesler had acquired permission, somewhat illicitly, to use an IBM 650 at Columbia University during unbooked slots on weekends. The 650 was about the size of three tall armoires standing back to back. Among its more curious features was its memory apparatus, a magnetic drum driven by an endless rotating belt like the fan belt of a car. The computer’s operators were indoctrinated with the stringent rule that if power to the system ever failed they were to wait a minimum of fifteen minutes before turning it back on, to make sure the drum could first come to a complete stop.
Left alone in the center one day, Tesler hit the wrong switch and inadvertently turned off the machine. “Instinctively I flipped it back on again—and the moment I did I went, ‘Oh, shit!’”
The belt instantly snapped with a report like a pistol shot. The harvest was a maintenance call to IBM, considerable expense to the computer center, and for Tesler a summons to the director’s office.
“He told me I could never use their computer again,” Tesler recalled. “That day I resolved that someday I was going to have my own computer, because I didn’t want anybody to ever do that to me again. And from then on many of my decisions about my life were weighed against the question: ‘Does this help me get my own computer?’”
Tesler’s second objection to POLOS was the hopeless inscrutability of its user interface. This violated another personal credo, that the programmer’s primary duty was to render the computer intelligible to the layman. By the time he reached PARC he had already written several programs aimed at turning computers into handy tools for average users, including one to print and format simple documents which he called “Pub” and sold commercially by mail-order.
Tesler had assumed that at PARC, the world capital of the interactive imagination, he would find everyone working toward this same goal. Instead he had been thrown among the POLOS team, which seemed bent on making things even harder for the user. He could not resist mocking the system and its silly theology. Every chance he could, he tried to show his smitten colleagues that Engelbart’s dazzling system was so complicated that it created more work for the user rather than less, like a telescope viewed through the wrong end.
“They had to justify the fact that it took people weeks to memorize the keyset and months to become proficient,” he recalled. “So they came up with this whole mystique about ‘augmenting intellect’ and how in order to become literate with a computer people would need six months of training. Basically, I showed that this stuff that took six months really only had to take a week, with the right system.”
Rather than heed his words, they shunned him like a parson at the orgy. “They were fed up with me and decided I was more of a pain than anything else,” Tesler recalled. “I was the naysayer. I was bringing down the morale.”
Finally Bill English summoned him to his office. “Larry,” he said, “we’ve found you a new assignment.”
While Tesler had been crabbing about POLOS from the inside, the system had been getting the once-over from a perceptive visitor from the outside. Timothy Mott had been dispatched to PARC as an emissary by the head of Ginn & Co., a Xerox subsidiary that published textbooks out of an office in Boston.
For a sixty-year-old publisher, this man, the provocatively named Darwin M. Newton, was an uncommonly enterprising individual. Sometime earlier he had discovered that Xerox was charging Ginn a portion of its annual revenues to cover “corporate research.” As far as he could tell, this tax had never purchased Ginn a dime’s worth of knowledge or technology, a deficit he resolved to correct. His inquiries led him to PARC, where he had received a short demo of the latest work on office systems—that is, POLOS. Newton returned home thinking that something like POLOS might help relieve the tedium of editing manuscripts and laying out pages, and in the process help Ginn turn out better books.
But the question of how to actually determine if his suspicions were right had him stymied. He knew everything about editing but nothing about computers. Then one day Tim Mott showed up for a job interview.
Mott was a displaced Briton with a computer science degree from Manchester University. This was a place with a much older claim to computing distinction than Palo Alto’s, for it was at Manchester that the world’s first electronic stored-program computer, based on the concepts of Alan Turing, had been built in 1948. After completing his studies Mott had relocated from Manchester to Oberlin College in Ohio, where he had spent a couple of years teaching math and helping the school set up its computer department. He then moved to Boston to enroll in business school. What brought him to Newton’s office was a tip that Ginn had a part-time opening that might tide him over until the school year started.
Once Newton learned that the man seated before him was a certified computer scientist, he jumped at the chance to explore how to apply the intriguing system he had seen in a real world production line. The part-time job suddenly disappeared. Instead, Mott found himself shipped out to Palo Alto with instructions to bring back POLOS as an editing system.
As a Briton, a stranger, and an ambassador from the far reaches of Xerox land, Mott spent his first few days on the West Coast with his head spinning.
“I had heard of PARC, though probably only through the stuff Stewart Brand had written. I didn’t think of myself as being in the mainstream of computer science research,” he recalled. What he found at PARC “from the standpoint of personal computing as opposed to either batch processing or time-sharing was really fascinating. And I got the joke about the price of the technology and where it was going and the fact that what was being worked on there was really going to be commercially viable, in time.”
But he also saw where the research train was going off the rails. On the POLOS team, he found, “there wasn’t a lot of time spent looking at what mere mortals would be able to do with the system.” Instead they had produced a system bewilderingly technical and counterintuitive. English and his software chief, Bill Duvall, had faithfully reproduced Engelbart’s system of “structured text” in which every line and paragraph of a file incorporated reference pointers to other pertinent text, allowing users to follow a sort of subterranean intellectual path through a document. Mott regarded it as a fascinating model for analyzing computer programs or navigating through information space. “But it wasn’t a particularly good model for editing manuscripts, let alone doing page layout of text and graphics.” Like Tesler, he shuddered at the thought of training a typical Ginn editor or secretary, or any ordinary user, to utilize POLOS’s baroque routines.
POLOS’s inadequacies in the real world posed a real dilemma for Mott. Since his charge was to study and adapt POLOS for Ginn, after six weeks in Palo Alto he had essentially studied himself out of a job. “My report back to Ginn was basically a letter of resignation, saying this isn’t technology you can use,” he recalled.
Fortunately, before sending it he happened to spend a few moments in Bob Taylor’s office, outlining his misgivings.
Taylor puffed at his pipe. “You’re not going to just go away, are you?” he asked.
“What choice do I have? This isn’t a system suitable for a publishing application.”
“So stick around and help us figure out what will work for Ginn. That’s why we’re here.”
Taylor’s proposal to Mott was not an entirely disinterested one. At that moment POLOS and the Alto were moving along parallel paths toward the same goal—delivering computing cycles interactively to users. Taylor figured the two programs were almost certain to end up vying for money and staff in a zero-sum game. He was not alone: Even observers with little stake in the success of either system realized that when the smoke cleared only one would be left standing. No one could be surprised that Taylor would do anything to ensure the Alto was the one that would prevail.
By 1974, when his conversation with Mott took place, this rivalry was already creating tension between the Computer Science and Systems Science labs. Lampson and his colleagues were convinced the POLOS architecture was obsolete. It was true that scrapping the traditional heavy-duty mainframe in favor of the Nova pool relieved the system of the memory management and job scheduling that made time-sharing so burdensome and complex. But since one or two Novas had to be reserved for specialized tasks such as scheduling print jobs and coordinated with the users of the pooled machines, the complexity got added right back in.
“It was actually worse than trying to do it on a classical time-sharing system,” Lampson explained later. “You had to keep all these balls in the air to keep everything working, which we’re not that good at today. And we certainly weren’t very good at it then.”
The CSL staff campaigned to undermine POLOS. If Taylor’s recruits from Berkeley Computer felt at all abashed about torpedoing the prize project of his recruits from Engelbart’s lab, they did not show it; this was a question of engineering, in which personal feelings were not a factor. In any case, English and his people now belonged to a different lab. In staff meetings and hallway bull sessions the Computer Science Lab never let slip a chance to make its views known, as though following the habit Bob Taylor had learned in his early itinerant years among the dusty little towns of rural Texas. They were making sure the Alto’s superior position in the hierarchy was established and rendered unassailable.
“We were saying our way is the right way,” Lampson recalled. “We openly articulated our feelings. We really thought they were doing the wrong thing and any resources poured into it were going to be wasted, as indeed they were.”
The POLOS defenders were equally spirited, arguing that CSL’s plan to distribute $20,000 machines to everyone in the building would be a ludicrous waste of resources, like giving every secretary her own printing press when all she needed was a typewriter. Not to mention that such a system would present a massive maintenance headache, especially compared to one where the most complicated machines were kept conveniently in one spot and the only distributed elements were essentially cheap, low-maintenance TV sets.
What may not have been clear at the moment was that POLOS was already in trouble—and for exactly the reasons Lampson cited. The system was too complicated and inherently inefficient to survive. The POLOS team’s inability to get the elaborate network operating consistently eventually became too obvious for even its staunchest advocates to ignore.
“We didn’t know how to deal with a system so complicated,” acknowledged Smokey Wallace, another ex-Engelbart engineer working on the project. In contrast to a modular system like Alto-Ethernet, where the whole system would keep functioning regardless of any one component’s failure, POLOS was so organically integrated that the crash of any one part would knock the entire assemblage out of commission, sometimes inexplicably. “It would run for three months straight and then fall apart for half a day,” Wallace recalled, “and we wouldn’t know why.”
Still, for more than a year after the Cookie Monster first munched its way across Chuck Thacker’s display screen, it was impossible to say which system would eventually prevail. POLOS still had a lot to offer, including the spectacular multimedia capabilities of Doug Engelbart’s NLS, reimplemented and in many respects improved upon. Meanwhile, the Alto was still looking for a rationale.
Taylor jumped at the chance to put Tim Mott to work. He knew Mott needed an alternative to POLOS. Clearly the answer would have to be the Alto. When he asked over at the Systems Science Lab if they had anyone with expertise in publication systems to work with Mott, Bill English suddenly recalled that Larry Tesler had done that “Pub” thing. Without hesitating, he called Tesler in to tell him about his new job.
“What is it?” Tesler asked.
“You’re going to do a publication system for Ginn,” English said.
By the time Mott and Tesler started working together, several prototype word processing programs had already been written at PARC. Almost none of them functioned very well on the Alto, however—they were too slow, or too elementary, or too complicated. The exception was Bravo, which was fast, rich in features, and well-tuned to the Alto’s capabilities.
Mott and Tesler, however, were among those who believed that Bravo, for all its marvelous endowments, harbored some major flaws. As with POLOS, most of these had to do with the user interface—the keystrokes, commands, and visual cues through which user and program communicated with each other.
For one thing, Bravo’s interface was heavily moded, meaning that the result of typing a key would differ depending on whether the program was in “command” or “text” mode. The operator always had to keep in mind which of these states the system was in, lest disaster ensue. In “text” mode, for instance, the system functioned like a typewriter: Pressing the “D” key gave you the letter D. In “command” mode, however, the keys produced not text characters but commands—pressing a D, for example, instructed the program to delete a selected block of text.
Modes were such notorious pitfalls in interface design that they had spawned a standard cautionary joke. This involved a user who inattentively typed the word “edit” while in command rather than text mode: Typing “e” selected the entire document, “d” deleted the selection, and “i” instructed the machine to insert in its stead the next character to be typed…at which point the user discovered that his entire document had been inalterably replaced by the letter “t.”
For the sake of the layman, Tesler and Mott believed, modes had to be exterminated. They thought Bravo’s interface represented a vast improvement over POLOS’s thicket of perverse and counterintuitive commands, but that it had not gone far enough. Its modes were simplified, but they were still modes, making it “still a very dangerous editor to use,” as Tesler recalled.
Moreover, like all CSL programs, Bravo was exceedingly ugly in appearance. For all CSL’s delight at its WYSIWYG capabilities, the program made scant use of the bitmapped screen’s graphical power. Even the variable fonts were still displayed as bare text on a blank screen. This reflected a deliberate choice by the CSL designers, who avoided elaborate graphics because they slowed down the system. But because the Systems Science Lab engineers were mostly interested in making the computer intelligible to the average user, they loaded up their programs with graphical gewgaws of all kinds, figuring that within a generation or two the machine’s speed would eventually catch up.
Tesler and Mott therefore set out to create a modeless graphical interface to make Bravo simple to use. Inspired by the costume Mott’s stepdaughter was wearing for Halloween that year, 1974, they called their new program “Gypsy.”
Their first step was to do something PARC had never tried before: They analyzed how non-engineers would actually use a computer.
This survey was conducted back at Ginn, to which Mott returned with an Alto display, keyboard, and mouse. He installed them as a sort of dummy setup (the machine was nonfunctional) and invited editors to seat themselves in front of the equipment, imagine they were editing on-line, and describe what they expected it to do.
“They were a little skeptical,” he recalled. “But—surprise, surprise—what you got was them wanting the machine to mimic what they would do on paper.” They even described the processes in terms of the tools they had always used. That is why to this day every conventional word processor’s commands for deleting a block of text and placing it elsewhere in a file are called “cut” and “paste”—because Ginn’s editors, the first non-engineers ever to use such a system, were thinking about the scissors and paste pots they used to rearrange manuscripts on paper.
While Mott was back in Boston studying the human factors, Tesler worked on the visual representation of the interface. His ambition was to build it around icons and menus—thumbnail-sized illustrations that would perform discrete functions when clicked with the mouse, and lists of commands that could be executed at any given time. For a while he almost started sympathizing with CSL’s view of how heavy graphics burdened the underpowered Altos: His first graphical interfaces worked so slowly that to demonstrate his scheme he had to record it on videotape at one-ninth normal speed so it would appear natural when played back in real time.
In 1975, after a year of work, Gypsy was ready for launch. Mott brought a couple of Altos and a high-speed Dover laser printer back to Ginn and wired them to a phototypesetter that would output camera-ready text. For the first time on such a large scale, professional editors manipulated text on a screen and stored it on magnetic disks rather than cutting, pasting, and marking a typed manuscript with progressively illegible changes.
“Initially the reaction to the concept was, ‘You’re going to have to drag me kicking and screaming,’” Mott recalled. “But everyone who sat in front of that system and used it, to a person, was a convert within an hour.”
In every way possible, Gypsy mimicked Ginn’s customary routines. The system retained multiple versions and drafts of every file and displayed them as a list. An editor could use the mouse to scroll down the list and click on the desired version to open it. (This was the first time the mouse was used as it is today, to execute point-and-click operations; Engelbart’s system and Bravo both used it simply to position the cursor within a block of text.)
Mott’s diligence in drawing the Ginn editors into the design phase paid off. Instead of an editing process “so laborious that there was a point at which you threw up your hands and said, ‘I just don’t want to do this anymore,’” he recalled, the Ginn staff “found the ability to edit on the screen and always have a clean copy improved the quality of the editing itself. They could do a lot more of it before it became frustrating.”
Within PARC, Bravo and Gypsy decisively tipped the balance in favor of the Alto over POLOS. Simonyi, Tesler, and Mott had shown that the Alto could support an interactive office system that worked fast enough to enhance—call it “augment”—the professional office worker’s intelligence. Since POLOS was slipping even further behind schedule, the success of the Ginn experiment sealed its doom. “The only real question,” remarked Ted Kaehler, one of Kay’s engineers, “was whether POLOS would be obsolete before it was even operational.” In the end, it was.