Header image
Word processors

The DEC Maynard MillIn 1963, I got a computer programming job for the summer at a start-up company called Inforonics, which had been founded only the year before. They had been contracted by IBM ("International Business Machines") to do a study of human factors in word processing. The company had offices adjacent to the old Digital Equipment Corporation ("DEC") plant in Maynard, Massachusetts, which was located in a group of former mill buildings (shown to the left). Note 1

Now, there really were no word processors to speak of in 1963. But the cost of computing was declining, with the arrival of minicomputers costing only a few hundred thousand dollars. IBM could see that it might soon be possible to attach a cluster of eight or sixteen terminals to a mini computer, in order to provide word processing capability to a secretarial pool in a large company. They wanted to try to understand if such devices would actually be accepted by users, and what might be the best sort of human interface to create. I don't think that at the time anyone considered the idea that a personal computer, dedicated to a single individual, was even remotely possible at a reasonable price.

To explore the issue of human factors in word processing, Inforonics had to first create a word processor with which to experiment, since at the time there were no commercial word processors available. Also, writing their own word processor would allow them to experiment with different human interfaces. Thus, they hired a couple of MIT students for the summer, Jerome Weiner and myself. I had just received my degree in electrical engineering from MIT that June. Inforonics rented time by the hour on a PDP-1 minicomputer owned by DEC, on which we programmed the word processor. Further down in this entry, below the horizontal line, I've included a few technical details about the word processing program we wrote, for any readers who might be interested (programmers, mostly).

Let me make my position clear. I was a programmer, one of two summer hires who worked on the word processor used by Inforonics in its testing. I didn't run the tests, nor did I write the final report to IBM. I may occasionally say "we" in what follows when I refer to Inforonics, but other than statements about the word processing program itself, my observations are second-hand, and others might have a different viewpoint.

Here's the rented PDP-1 used for the research
PDP-1 used by Inforonics
The picture above was included in the final report submitted to IBM.Note 2
That's Inforonics founder Larry Buckland seated at the terminal.

The PDP-1 minicomputer itself is the tall unit to the left of the picture. The input-output devices connected to it were a graphical display (in front of the operator, I think a DEC 340), and an electric typewriter by Friden, based on the Friden Flexowriter. The latter was interfaced to the computer so that the computer received a code whenever a key was struck on the keyboard, and the computer could send out codes to cause keys to be typed. Note that the Flexowriter keyboard, like any standard typewriter keyboard, lacked the extra keys that are now found on personal computer keyboards. That is, it had no cursor control arrows, no "Ctrl" (control) key, no "Alt" key, and no function keys. It did have the ability to shift its ribbon so as to make it type in either black or red.

And it goes without saying that there was no "mouse". That very same year, 1963, Douglas Engelbart and Bill English were producing the first mouse prototype at the Stanford Research Institute. But the mouse really wasn't widely used until the release of the Apple Macintosh in 1984.

However, the display unit did include a "light pen", a photo-electric device which could be used to select a displayed character by pointing the "pen" at it on the screen. Some of the research considered the use of a light pen as a selection device. Having to account for a light pen also affected the design of the software, which had to locate the light pen "hit", and relate it to the location of the selected character in memory.Note 3

We initially wrote the word processing program to accept its editing commands from the standard typewriter keys. This meant that at any given moment, the program was in one of two modes, called "Control Mode", and "Text Mode". I need to say here that our on-screen "cursor" was a small caret under one of the letters, rather than a bar between the letters as is common in modern word processors.

In Control Mode, the typewriter typed in black, and characters typed had the effect of being commands to the program. Thus, for example, typing a <space> moved the caret one position to the right, and hitting the <backspace> key moved the caret one position to the left. Typing a "u" moved the caret up, and typing a "d" moved the caret down.

Other commands required multiple letters, although all commands were short. "cc", "cw", and "cl" were "change character", "change word", and "change line", respectively, and similarly "ic", "iw", and "il" were "insert character", "insert word", and "insert line". After these commands, the editor went into "Text Mode", in which everything typed up to an "Enter" key was interpreted as text to be inserted into the document. That text would either replace the character, word, or line in the case of a change command, or be inserted in the event of an insert command. In "Text Mode", the typewriter typed in red.Note 4

Inforonics thought that professional typists, who were not used to using a computer, would not want to memorize a large number of commands, but rather would prefer a simpler interface. Consequently, we built what we called a "Button Box". This was a slanted panel covered with labeled buttons, used only when we were using the system. We took it away at other times, because Inforonics was only renting the computer, and the work we were doing was confidential. The button box is shown below:

The button box
The picture above was included in the final report submitted to IBM.

Of course, Inforonics also had to build an electronic interface board to the PDP-1 computer to connect it to the Button Box. The Button Box included cursor control buttons, like a modern personal computer keyboard (you can see them in a diamond configuration in the photo above), and other buttons corresponding to the commonly used editing commands.

I've gone into all this detail so that you can understand the events described below.

Once the word processing system was working, testing began. Inforonics hired professional typists from "temp agencies" (organizations that provide temporary workers to companies in need of extra help). They specifically wanted to test the system with professional typists, because large company secretarial pools were seen as the natural customers for word processors. Nobody could envision expensive systems of this sort being used by anybody else.

But would these typists be willing to use the system? Would they learn it easily, or would they find it too difficult? Would it speed them up, or slow them down? Inforonics first tested them using standard electric typewriters, having them copy text from library catalog cards. Then after training them in our word processing system, Inforonics repeated the tests using our program.

Despite having no previous experience with computers of any sort, the typists found it quite easy to learn the system and to use it. It also sped them up, as no matter how experienced, all typists do make errors. With the computer, errors could be immediately corrected. Serious errors found only on proofreading could also be fixed quickly, whereas with manual typewriters, entire pages had to be completely retyped.

We found out how much they liked the system when we came in to run some tests one day, and found that the PDP-1 computer was down. Since we had already hired the typists, and had to pay them for the agreed-upon time, we tried to go back and do some testing with standard typewriters. Some of the typists virtually refused, saying they'd rather wait for the computer to be working. Once having used a word processor, they didn't want to go back to the old way of doing things. It quickly became clear that the word processor was thought by users to be a decisive improvement over a standard typewriter.

But the real shocker came a bit later, when I came in and found one of the typists working with the button box pushed aside, out of reach. When I looked to see what she was doing, I found her using the "Control Mode" keyboard commands, which I thought we had never told the typists about at all. She apparently preferred typewriter control to using the Button Box. That didn't seem reasonable to me, as the button box made entering commands so simple - just press a single button. Why would she prefer the typed commands?

Waiting until the end of the test, I asked her about it. Her reply was very instructive. She said, "Honey, I type easily 90 words a minute. Do you know how many characters I could have typed in the time it takes me to push one of those buttons, and then reposition my hands on the keyboard? If I never take my hands out of the standard typing position, I can go much faster. Learning a few command abbreviations is not much of a price to pay. There aren't that many of them, and they're very easy to memorize." Other typists who were taught the "Control Mode" method subsequently confirmed her observation.

So the eventual Inforonics report to IBM included the note, "The fastest control of the editing process was accomplished by a touch typist using the typewriter for the entry of both commands and new text. Somewhat surprisingly it was not found difficult for the operator to mentally transform the keyboard between a text input device to a control device."

Why don't word processing programs on personal computers work that way? In fact, although I myself would like to see one, I don't know of any commercially available word processing program that doesn't use cursor keys and drop-down menus or control keys. And the reason has to do in part with the history of personal computers.

As it turned out, personal computers didn't come into the office initially for use by professional typists. The first people to obtain them were generally office personnel who didn't type for a living, and who were generally not touch typists at all. Most of them were so-called "hunt and peck typists", who didn't care whether their hands stayed in the standard touch typing position or not. Consequently, word processors are not at all optimized for touch typists. If you are a touch typist (as I am), you find that these programs require your hands to be removed from the standard typing position, and then re-positioned, repeatedly. Note 5 

Things don't often work out the way you expect.

About the word processor we wrote
(This section is for you programmers)

Our word processing program was written in a PDP-1 assembly language called DECAL, created by computing pioneer Ed Fredkin, who actually came by one day to talk to us about it. The PDP-1 read and produced punched paper tape:

Fan-folded paper tape

Most assembly programs are what are called "two pass assemblers", meaning they have to read the source code twice. On the first pass, they construct a symbol table giving the locations of all the variables used in the program. Then on the second pass, they can fill in all the references to these variables. While having to read the source code through two times would not be a big deal nowadays, when you had to read it off a punched paper tape, it could take a few minutes for each pass (although the photoelectric reader was pretty fast).

DECAL, however, was a single pass assembler, which only had to read through the source code once. Like other assemblers, it would then produce a so-called "object tape" for the linking loader, tacking the completed symbol table onto the end of the object tape. The trick used by DECAL was that the linking loader read the object tape backwards - you turned it around, and fed it into the reader tail-end first. The loader would then encounter the definition of a variable before encountering any references that used that definition.Note 6

The PDP-1 computer used 18-bit "words".Note 7  DEC computers used the ASCII code, a seven bit code, to represent their characters internally. Therefore, only two 7-bit characters could fit into a computer word. With the large memories of today, this would hardly be a problem. But in 1963, memories were very much smaller. Very, very much smaller. The basic PDP-1 could address only 8K (words) of memory, which is probably what we had available to us at Inforonics. In modern terms, that's equivalent to 18 Kbytes. That's 18 KiloBytes (18,432 bytes), not MegaBytes (let alone GigaBytes).

So with memory at a premium, I used only a subset of the ASCII code, and represented each character using only six bits (the so-called "six-bit code"). Since I could then pack three characters into each word, this allowed me to get 50 percent more characters in the space available, allowing us to process larger text samples.

However, six-bit code only allows for the uppercase characters, and has no room for the lowercase ones. Add it up - six-bits only gives you 64 possible codes. The 26 letters plus the 10 numbers and at least 28 assorted punctuation and control characters (including a space and a newline character) already add up to 64, leaving no room for another 26 letters. This problem is solved by including among the 64 possible codes an uppercase-shift-code and a lowercase-shift-code. Each code can then represent two different characters.

This does mean, however, that you can't just look at a six-bit character in memory and know what it represents. You also have to know which case is in effect at that point in the text. If you haven't kept track of it up to that point, you can scan backwards in the text until you encounter the last previous case shift. I recall spending a good deal of time writing code to take care of all this in an acceptable amount of time, and also code for packing and unpacking the characters, each of which could be in one of three possible positions within the word.

Of course, for us, the PDP-1 was in fact used as a "personal computer" - one user at a time. I think we paid $40 an hour for it, in 1963 dollars.

Footer image

Next in blog     Blog home     Help     Next in memoirs
Blog index     Numeric index     Memoirs index     Alphabetic index
© 2011 Lawrence J. Krakauer   Click here to send me e-mail.
Originally posted December 29, 2011

Footnotes image

Footnotes (click [return to text] to go back to the footnote link)

Note 1:   I've gotten in touch with the founder of Inforonics, and president in 1963, Larry Buckland. He wrote, "I recall fondly your mother writing me a very nice letter thanking us for providing you summer employment." Sounds like something my mother would have done.   [return to text]

Note 2:   The report submitted to IBM at the conclusion of the research was entitled, "Study of the use of man-machine consoles for text processing, Final Report of Work Performed from May 20 to December 6, 1963 under P. O. No. RX39409, Submitted to International Business Machines Corporation, Thomas J. Watson Research Center, Infor/onics, Inc., December 6, 1963". The principal investigator was the president of Inforonics, Lawrence F. Buckland.

The report acknowledged the project staff who performed the work: Ann Hureau, Lawrence Krakauer, Joseph Lundy, William Nugent, Maxine Nyquist, and Jerome Weiner. The report on the results of the research comprised pages 1 through 24. The remaining pages comprised Appendix 1, giving a detailed description of the word processor program called "Edit Display" (23 pages), the operating instructions (3 pages, authored by me), and a dictionary of registers and subroutines (30 pages).   [return to text]

Note 3:   A 1965 report by W. K. English, D. C. Engelbart, and Bonnie Huddart can be found on the NASA Technical Report Server, under the title, "Computer Aided Display Control" (a PDF file). The report was prepared for NASA by researchers at the Stanford Research Institute ("SRI").

Note the picture of the mouse in Figures 13 and 14 (page 91 of the report, page 96 of the PDF) - it's a square box. The paper also reports on experiments with a cursor positioning device operated by the user's knee, presumably to enable the user to keep his or her hands on the keyboard. There's a picture of it, seen from under the table, in Appendix B (page 94 of the report, page 99 of the PDF). I guess that idea didn't catch on.

The SRI paper also includes in its bibliography a reference to the Inforonics final report (on page 100 of the report, page 104 of the PDF). Thus the report that Inforonics submitted to IBM had evidently made its way to the Stanford Research Institute, in Menlo Park, California. But the Inforonics report doesn't seem to be available on the NASA Technical Report Server.   [return to text]

Note 4:   There were 41 different commands, grouped into the categories "Display", "Caret control", "Editing functions", "Input", "Output", and "Miscellaneous". Among the commands was a "tp" command to "Transpose the letter over the cursor with the letter to its immediate right". The final report noted, "... the complex command TRANSPOSE was found to take longer to use than the simple CHANGE WORD when changing a transposition spelling error."   [return to text]

Note 5:   When my daughter Elissa was a child, she decided, for mysterious reasons, to type a piece of school homework, instead of submitting it in handwritten form. Perhaps she just wanted to play with my portable typewriter, but after a while, I noticed that her hunt-and-peck typing was taking quite some time. Since she had already completed the required work, and the typing was just an afterthought, I offered to finish the job for her.

She watched as I set up her handwritten text on a stand. Then, my eyes fixed to the text, I began typing it at a pretty rapid pace, and Elissa's jaw dropped. She was stunned, and exclaimed, "You're not even looking at the keys!" I explained to her that it was called "touch typing", and was a skill I had learned in High School. She had never seen anyone do it before.

I first told this story in an earlier blog entry called Magic.   [return to text]

Note 6:   When I worked at Micronetic Systems (see my earlier entries "Micronetic Systems" and "Madhu and the death ray"), I had another experience with a paper tape being loaded backwards, except that time it was by accident. We had built a laser trimming machine which we sold to Bosch, which used it to produce an automotive carburetor. Air entering the carburetor flowed through a device they called in German a "Luftmengenmesser" ("air flow meter"). It provided the fuel injection system controller an electrical resistance proportional to the airflow through the device. The flow was measured by a spring-loaded vane deflected by the incoming air. The deflection swung a wiper along a thick film resistor, forming what in electrical engineering is called a "potentiometer".

During production, each airflow meter was separately calibrated. A separate machine blew varying amounts of air through it, and recorded its deflection at each airflow level. The results of this test were punched on a paper tape. Our laser trimmer then trimmed the values of a group of resistors in order to tailor the output of the potentiometer to the results of the airflow test. When we were done, the output of each airflow meter was an accurate measure of the airflow.

Although it was used by Bosch in Germany, our machine put out most of its instructions and error messages to its programmers in English, which was no problem for the German engineers. However, any errors that came out during the actual production process itself had to be read by the production workers, so those messages were translated into German.

At some point, a Japanese company licensed the carburetor design from Bosch (I think it was Toyota). A group of engineers from that company came to Boston to look at our machine, considering purchasing it for their own production process. We figured we were a pretty good bet to obtain the order, because Bosch itself had used our machine. We demonstrated the entire process, feeding a paper tape into a reader attached to our machine, and demonstrating how it caused the machine to properly trim the resisters on the airflow meter. One of the visiting engineers wanted to try it himself, to get a feel for how easy it was to load the airflow meters into our laser trimmer.

That was a two-part process, which included placing the airflow meter on a carrier, then putting the paper tape into a reader and pressing the start button. Unfortunately, when he put the tape in the reader, he put it in backwards. This caused an error tone to sound, and the attached terminal printed out, in German, the error comment "Datenstreifen umgekehrt"("Data tape reversed"). I was amused to watch all the visiting engineers start thumbing through their English-Japanese dictionaries to try to figure out what this meant. We had to hasten to explain to them that because this was a machine designed for Bosch, the comment was in German, and not English. By the way, despite our confidence, we didn't get the order (perhaps they did the job themselves).  [return to text]

Note 7:   You can actually find a complete manual for the PDP-1 online, by clicking the underlined link in this sentence. I have an old paper copy myself.   [return to text]

Bottom image