Let’s start this month with an interview. Larry Tesler helped lay the foundation for the computer interfaces we use today while working at Xerox PARC and Apple. He conceived the idea of “copy and paste” at Xerox and worked on the Apple Lisa and Apple Newton. Unfortunately, we lost Larry 4 years ago.

Note: The last page of the interview has some scan issues and some of the words are missing. This is the only copy of this issue of UNIX Review that I could find.

from the July 1985 issue of UNIX Review

OF MICE AND MEN

An interview with Larry Tesler

The worst problems occur when people walk into their office and—without warning—find technology they never asked for.

There aren't many veterans of the computer industry who have tracked the history, promises, and prospects of office automation as closely as Apple Computer's Larry Tesler.

Following graduation from Stanford University in 1965 and a brief foray into the fledgling field of artificial intelligence, Tesler joined Xerox PARC in 1973. It was there that he encountered some of the earliest versions of “office augmentation" products. Arguing that OA systems needed friendlier interfaces in order to grow, Tesler helped pioneer a series of changes designed to make the machines look “more like familiar objects" to their users. As part of this effort, he studied computer training and employee transition problems in the workplace.

Tesler joined the Lisa development effort at Apple in 1980, and then moved to the Macintosh Group in 1984 to serve as Manager of Future Architectures. That's where Dick Davies quizzed him for UNIX REVIEW on the trends he sees in office automation and the ways in which he feels the UNIX operating system plays a role.

REVIEW: How did you first become involved with office automation work?

TESLER: I was in on the beginnings of what’s now called “office automation” at Xerox PARC in the early '70s, but let me say that I don’t really like the term “office automation” because it conveys the image of an office that runs itself automatically, like an automated factory. The image is one of people running around twisting knobs that help the office work. Offices will always be run by people, at least for the foreseeable future, so what we’re actually automating is some of the busywork that people do.

REVIEW: What surprises have there been?

TESLER: Actually the main surprise for the people who originated the notion, like Doug Engelbart, has been that it has taken so long. He expected the office automation push to be something that would have already been achieved by now. Another surprise has been that, unlike the image people in the ’50s had of a giant computer with a million terminals, we now have a lot of very cheap workstations that can be networked together. That has had an impact on how people view office automation. Still another surprise has stemmed from the expectation the original developers had that office automation would be such an important tool for people that they would be willing to spend a lot of time training, just like they spend a lot of time learning to type or learning to drive or learning to take shorthand. We haven’t seen that, though.

I got involved in all this in the early 1970s—at just about the time it was becoming clear that in order to get people to accept this kind of technology in their office, it would have to be something that could be quickly learned. So, my focus from the start was to develop office automation tools that could be learned in minutes, hours, or days, instead of over the course of weeks and months.

REVIEW: Like a good word processing system?

TESLER: Right. We started by looking at the NLS system Engelbart’s group had developed at SRI in the ’60s.

REVIEW: That early?

TESLER: Yes, they invented the mouse in 1964 or ’65. But it was a pretty clunky mouse, since NLS had a page-sized display. Some versions of NLS had a little bit of line-drawing graphics. But most had no graphics or graphics that were very crude. One version, though, did have the ability to superimpose video on the screen along with the text, which was a very powerful capability that’s only now beginning to be reintroduced. In many ways, there were features of that early system that are still not available to most people. The NLS system is now marketed by Tymshare as *Augment*, but it’s gained little acceptance despite its power because it's relatively hard to learn.

For all that, the point is that even at that early date those developers were able to produce a full-page screen and a capability that’s now called “outline processing”, as we find in ThinkTank and Framework. They also had something which is called “Hypertext” now. That’s a capability that you’ll see coming out on personal computers very soon. Hypertext systems allow you to look at a document and see a cross-reference citation to another document. You can then point your mouse to something and say, “I want to see that,” and the system will bring that document up onto the screen.

NLS was quite an amazing system. There were two reasons it wasn’t accepted. The one that everybody understood was that the technology was very expensive. It cost $100,000 for one of these machines, but the price of it was expected to drop. The founders of PARC extrapolated the price of hardware and realized that in the ’80s the hardware would become very cheap. They expected you’d be able to get something like an NLS System for something in the range of $1000 to a few thousand dollars. Their vision was that they would bring the price down on the system and then improve its user interface.

They weren’t exactly sure, though, of how they were going to deal with the user interface. That’s the part I got involved with—the development of a very fast user interface that could be learned quickly. In that effort, I started doing something which the SRI and PARC researchers had not done before—I started letting users test alternative interfaces while I observed them as a psychologist would.

I’ve used that methodology ever since. We used it in the design of the Lisa and the Macintosh at Apple. The idea was to sit people down and let them use the system. In the process of observing them, 1 noted why they were having problems. Up to that time, whenever people had problems, the advocates of difficult systems would just declare philosophically that, well, these things are just hard to learn, but because they’re so powerful, people will just have to learn them.

REVIEW: That also answers the question of why acceptance took longer than some of the original founders thought it would.

TESLER: Right. It wasn’t just price; it was the difficulty of learning. There was resistance to the complexity so I developed a word processor which was actually the first word processor to run on Xerox’s personal computer prototype, the Alto. The program was called Mini-Mouse, and a user could actually learn how to use it in five minutes. It wasn’t very powerful. All it could do was insertions, deletions, movements of text, and searches. It offered fixed-pitch fonts but no proportional fonts. But when we took people right off the street who could type but had never seen a computer, they were able to use all the features of the system within five minutes.

Critics complained that Mini-Mouse wasn’t very powerful—that it didn’t have all the great features we needed. But it proved the point that simplicity was possible. The next problem was to figure out how to apply these principles to all the other things people need to do in offices besides typing little memos. That’s what we spent the next seven years working on.

REVIEW: What kind of productivity improvements could you measure?

TESLER: There was no difference, of course, in the typing of a document—that always takes the same amount of time. But when a user went back to edit a document, it was twice as fast using this system as it was using standard systems like the Wang. It was also two to four times quicker to learn than any other system around, and for some systems the difference was even higher. So Mini-Mouse offered both faster editing and faster learning. It also proved that you could make systems that were easy to learn.

In fact, the best way to learn interactive systems is to have a tutor who gives you a brief demo, and then sits with you and coaches you as you use it. That seems to work best for all systems. The other way is to do a similar thing with a book, a tutorial—preferably an online tutorial.

If we make the computer look like a familiar object to a person, like a typewriter or a telephone or a filing cabinet, then we’ve made it more intuitive and easy to learn. If it looks like a programmer’s idea of a computer, with commands and statements, then this will only serve to confuse a person. On a typewriter, carriage returns go to the next line. On some computers, carriage returns terminate a command. That can really throw beginners. On a typewriter, the typing of letters puts text into your document. On most computers, typed letters can also be interpreted as the names of commands. People just aren’t used to the idea that typing has two different functions. They’re not used to typing commands. They’re used to typing information.

We weren’t the only ones to discover this. Companies like Wang put function keys on the keyboard. That was much clearer to people. The function keys were more like the ones people had used on typewriters for single spacing, double spacing, and backspacing, among other functions. But the trouble with function keys is that when you build 82 function keys on your keyboard and your program has 82 functions, you’re in trouble when you want to expand by adding networks and other things because you’ve run out of functions. So we threw all the function keys off the keyboard, except for the ones we couldn’t, like backspace and carriage return. In their place, we put menus on the screen. Having a mouse, people could point at menus. That was the basic idea we developed at PARC in the early ’70s.

NLS had the right idea in using a mouse and a full-page display, but it was wrong in the way it used letter keys to specify commands and in the way it was generally based on a computer model. Another thing NLS had was something we call “modes”, like “insert mode” or “move mode”. One of the things I discovered in my studies was that modes really confuse people. The people designing systems never seemed to take it as a challenge that they should do something about. They simply assumed users would have to learn about modes.

I decided, though, that we could eliminate modes, or at least some of the really annoying ones like “insert mode” and “replace mode” and “overtype mode”. They’re just totally unnecessary.

REVIEW: But modes are still widely used in some systems.

TESLER: And those are the systems that are hardest to learn. Now, that brings up the question of the kinds of resistance older workers have shown.

REVIEW: You mean the sociological impact?

TESLER: Yes. When you try to teach people to use one of these programmer-oriented systems—the ones that completely defy the intuitive models people have of how their jobs work—there will often be resistance. If you give them something which works in a way they’re used to, there’s going to be a lot less resistance. I think this has less to do with user interface and hardware, though, than it has to do with sociology— that is, with the way that technology is introduced into the office. Making user interfaces simpler and offering better training will lessen the time it takes to learn these systems, and it will also improve the response people have to them. But the question of whether these people will be willing to accept the system in the first place has much more to do with how management introduces it.

The extreme case is when the workers come to work one day and find that their typewriters are gone, with word processors set down in their place. Now, if on top of that, the word processors are hard to learn, you’re certain to have trouble. But the worst problems occur when people walk into their office and—without warning—find technology they never asked for. If workers are involved in the selection and evaluation of equipment from the start, they’ll be waiting for it when it arrives. But if, in the workers’ minds, you associate layoffs with the arrival of new equipment, that’s going to be a problem. Of course, the workers who stay will eventually get over that, but it becomes a tense situation. Companies that arrange for displaced workers to move to other parts of the company, or who introduce outside methods slowly and use simple attrition to take care of displaced workers have far fewer problems than those companies that abruptly shift over to computers. Suddenly in that situation, instead of 20 people and 20 typewriters, there are 10 word processors, 10 unemployed people, and 10 insecure people.

REVIEW: And then the surviving employees get marched off to a training class.

TESLER: Yes. Those are the people that display the most resistance. This has been the real problem people have had with office automation.

REVIEW: Let’s bring this discussion right up to the moment. Are there other problems with office automation that really stand out? A lot of things are happening in the field now. You've got the introduction of a whole new set of high-level power tools: graphics, communications, and electronic mail, to name a few. All bring symbolic changes. What are the problems you see this causing at this level, right now and in the next generation?

TESLER: Well, at this point I don’t think the main problem with these kinds of technologies lies in the introduction of them. I don’t think people are as resistant as they once were. Most people want a computer. They know computers take care of a lot of drudge work.

REVIEW: Electronic mail is showing up on more systems. What do you feel the importance of that will be?

TESLER: First of all, a lot of the current electronic mail systems have terrible human factors. They are hard to learn and hard to use. What’s more, people can’t do what they want with them. Things like easy editing and easy filing and retrieval just aren’t there. I don’t think people appreciate what they could actually do if they had electronic mail that offered good human factors.

A lot of companies have to use more than one electronic mail system. They’re communicating within their own building, to other parts of the company, or to remote sales offices or something, so they might be using two or three different mail systems. In addition to that, they’re probably also using a public network like CompuServe in order to access databases. These folks have a serious communications problem since they have to use, and learn, so many different systems.

REVIEW: That's creating a class of specialists in many companies.

TESLER: Right. So I think the answer that’s coming is the advent of what are known as “front-end” electronic mail systems. An example is the Transend System for the IBM PC that offers a single user interface that can be used to access all of your communications systems. Under this sort of scheme, it becomes the job of something called a “protocol language” to figure out that when the worker says to delete a particular message, this means to do one thing on one system and quite another on a different sort of system. The user never has to know that. He just communicates his desires by way of icons and that sort of thing.

There is another side to the acceptance issue, which is overuse. It used to be that if you wanted to send a letter to 100 people, you had to type 100 letters. So you thought about it: “Is this really what I need to do?” Then, when we got word processors, you only had to type one letter and one mailing list, and then run Mail Merge. After that, you just had to make sure the printer didn’t jam. Still, somebody had to stuff 100 letters into envelopes and put stamps on them. So you thought again, “Do I really want all 100 of these people to get this letter?”

With electronic mail, though, you write a letter and you say, “Send it to distribution list X”, carriage return, and that’s that. All of a sudden, 100 people receive a message. It doesn’t take any extra effort on your part. Unfortunately, it costs these 100 people extra effort to look at the message and decide whether it’s of any interest to them. So you end up with a junk mail problem. When it gets easy to distribute mail, it gets hard to filter it. I don’t know how many places are running into this problem now, but it’s inevitable. I know we ran into it at PARC years ago.

Public networks already have rules of etiquette about how to answer somebody’s message. Even though a single keystroke is all it takes to send a reply off to everybody else who received the original message, these rules say, “Don’t do that. Nobody else wants to see your answer to the message.” The default of the system itself should be to reply only to the person who sent the original message. Rules of etiquette aren’t the way to solve the problem. The vendors should fix the software so that it doesn’t make undesirable options easy to use. For example, we want to make it difficult for people to read other people's mail. We also want to make it difficult for people to steal confidential information. We don’t want ease of use to get to the point where it’s easy to steal other people’s property. It should also be difficult for people to flood the network with junk mail, like responses to other people’s questions. And it should be easy for you to answer questions that are put directly to you. For example, if you get mail from Joe, you shouldn’t have to type his entire network address in order to answer his question.

REVIEW: Let's pick up the UNIX angle for a moment since you're getting to the issue of what's difficult and what's easy, what's accepted and what's not. There are a lot of advantages to UNIX — portability, communications, multiuser capabilities, and so on. But what are the disadvantages?

TESLER: I agree that portability, communications, and multiuser capabilities are the advantages. I think human factors is the weakest area.

REVIEW: Are you referring to the length of learning time that's required and the fact that the system doesn't use icons?

TESLER: There’s also a reliability problem.

REVIEW: Let's start with that.

TESLER: Advantages and disadvantages tend to come together. Multitasking is one of the great advantages of UNIX. It’s important in the workstation area, where a user might work on three different tasks in a five-minute period. For all that, the disadvantage of multitasking is that if the system crashes, then all the tasks crash. So when a shared resource like a database server, a file server, or a large shared computing engine crashes, everybody using that system has to stop working.

REVIEW: Let's talk about the user interface.

TESLER: User friendliness is where UNIX completely falls down. An example is a UNIX mail system. Say you bring UNIX into an office and you tell the people there who have never used UNIX before, “You’re going to have electronic mail. You don’t have to learn all of UNIX. All you have to learn is electronic mail.” Well, it’s just not so. They’ll have to learn how to log in. Hopefully, you’ll already have some wizard in place who can set up their login files. Otherwise, they’ll be completely lost, spending months getting their login files right. Hopefully, someone’s already given these people a list that tells them about all the mail commands and what they do. But when they read that list, they won’t have any idea of what it means. There are a lot of strange conventions they’ll have to adjust to. Upper case means one thing, lower case means another. This strange, cryptic code puts users off right away.

But let’s say these people go to a good training session where someone takes them through the system slowly and teaches them about the mailing system and all its subtleties. After a few days, they should be able to check their mail, file their messages, and answer their messages. But let’s say a user is typing a message and needs to edit it. Now he needs to know the magic thing to do to get into an editor. Then he’s got to learn how to use the editor. The editor has nothing to do with the mail system, but he’s got to learn ex, ed, or vi, or whatever, just the same. Of course, the editor has a whole different command system than the mail system does, so some of the same commands mean different things, and many of the conventions are different.

So after your users have learned to deal with the shell, which has one command language, they’ve got to deal with the mail system, which has another command language, and then they’ve got to deal with an editor that has still another command language. Not only are the mnemonics different, but so are the conventions. It just doesn’t have to be that way. A nice electronic mail system will, with a mouse, display your mail in windows. You can then edit it the same way you edit your memos, and after that you can go to a menu and indicate that you want to send a memo, and the system will give you a list of people you can select from by using a mouse. Then you click an “ok” button and you’re done. There are variations on this, but there are a number of mail systems that operate in just this way. What you teach users is how to edit. If you make it easy enough, an editor can be learned in an hour—and it can be made into something that people won’t forget.

But once people learn UNIX, they’ve made a big investment, and it becomes a challenge to increase their knowledge of the system. Once they have a stake in it, they resist the idea that other people might learn how to do something similar in an hour—even though it took them three months. These people then become UNIX “advocates”.

REVIEW: So there's a built-in resistance to simplicity?

TESLER: Right. If someone gives these people an easy-to-learn system, it’s going to be hard for them to learn. By then, they’ve got it completely wired into their brains that commands are to be typed on a keyboard. Their immediate reaction to a mouse is that it must be slower, it must have fewer features, or it must have something that’s bad, because otherwise how could it be so easy? This suspicion results from a built-in resistance and it causes a problem. UNIX users generally say something like, “I don’t need these features.” That, in a sense, may be true, since they’ve already made an investment of time in learning to do things another way. The problem is, organizations are going to have new employees coming in, and these people might easily do something unintentionally—like delete a file or a directory full of files. There’s no opportunity for confirmation and there’s no way to get the file back. Bang! It’s gone. And where did it go? That’s why UNIX is an unsafe system for an office.

UNIX was designed for programmers—that is, full-time programmers who are experts and don’t want to be bothered with extra confirmation keystrokes, because they’re afraid they’ll get slowed down. They know about regular backups and all the other things programmers do. But even then, programmers get themselves in trouble under UNIX and complain about it. But at least they’re programmers and so have an understanding of how computers are.

REVIEW: They're looking for speed and power, not ease of use.

TESLER: Right. Often a programmer will delete a program accidentally, and then spend an hour trying to reconstruct it. He doesn’t realize that the seconds he’s saved by not having to hit a confirmation key or by not having to type an extra character is nothing compared to the time he’s lost trying to find a backup tape and make all his changes over again. But programmers will be programmers. There's no way, though, that an office manager should accept that because there’s no need for it.

REVIEW: Is there a way to blend the best from UNIX and systems with friendlier interfaces?

TESLER: One of the great things about UNIX is the ability to have shells like the Bourne shell and the C shell. One thing that’s amazed me, though, is that so little work has been done to develop a portable window shell. Actually, they’ve worked on a window shell at Carnegie-Mellon under a contract with IBM. It runs on a Sun workstation. And Sun itself has a window shell that runs on UNIX. [AT&T’s UNIX PC, designed by Convergent Technologies, also offers a window shell.] But I haven’t figured out why there isn’t a standard window shell that’s portable and can have device-dependent drivers that make it work with any particular screen.

That would take care of one level of the problem. But you’d also have to go further. You’d have to provide a mouse, menus, icon-oriented text editors, icon-oriented mail systems, and everything else. What we need is a whole new applications software set. The reason I think it hasn’t been done is that it would be such an enormous development job. Even given the current programming tools on UNIX, it would take years to develop all that software, and it would make UNIX even bigger than it is already, which is awfully large. You’d also have to decide if you were going to throw away the old shells and the old editors, and there would be a lot of resistance to that.

In general, I like the UNIX operating system, but there are some features I wish it had. It doesn’t lend itself well to Macintosh-style software that offers smooth mouse motion, it turns out. So that’s a big problem you have to deal with. But if you were able to provide all the nice user interface features you need and if you were able to improve the operating system to support them and do all the other things you need to do, would you then still have UNIX? Maybe the thing to do is to start with UNIX and develop it into something that addresses these problems, or maybe the best thing is to start over from scratch.

REVIEW: Can UNIX help propel office automation at all?

TESLER: I think the important thing that UNIX offers office automation is not workstation software, but server software. Servers don't have a user interface, or if they do, only one person in each organization has to deal with starting it, scavenging the disk, and so on. It doesn’t bother me that one trained person needs to be in the organization to deal with the UNIX shell. If the server runs UNIX, that’s great, because then we can have electronic mail server software, database server software, file sharing server software, and print spooling server software—and all of it will be portable from server to server because it all runs on UNIX.

REVIEW: Aren't you describing the direction Apple itself is taking to some extent with its automated officeware? Or with its server concept?

TESLER: Oh, right, I see you know about the Lutzky-Baird system.

REVIEW: Exactly. I was going to ask you about that.

TESLER: Lutzky-Baird has a system that runs on a Zilog computer that works as a UNIX file server. It runs a file system and communicates over Apple-Talk to a Macintosh running Macintosh-style applications, with no UNIX evident to the people who use the workstation. That’s a very good example. I expect you’ll see more of that kind of thing.

REVIEW: Now let's take that and merge it into the question of where OA is going, irrespective of operating system.

TESLER: There are two issues. One is greater market penetration, and the other is more augmentation for the people who already make use of office automation. Greater penetration is an issue that hinges on ease of use, marketing, sales, features, and other things. But let me turn my focus to augmentation. It doesn’t matter whether you’re using office automation now. The question is: what will happen to your use of it later? As for the directions of the industry, consistent user interfaces are an obvious need I don’t have to go into. Networking and electronic mail are also topics that are pretty well known. So let me talk about some things that are less well known.

One coming trend is that personal computers will be used as friendly front ends to software running on mainframes and servers. The Transend PC is an example. The Lutzky-Baird system is an example. There’ll be lots more of that, with software running on a big system offering shared resources, and with a consistent user interface that allows users to interact with the system—whether it’s in the next office or located across the country, or whether it’s on the same brand of computer or a competitive make. Not only will this interface be friendly, but it will be integrated. You'll be able to take data that you bring down from one mainframe and integrate it with data that you’ve brought in from some public network. You’ll then be able to integrate that with data you've produced yourself. You’ll be able to analyze it locally or analyze it on the mainframe. One of the technological problems is how to get the data to flow readily. People are having a problem now with that. They need to download software from the mainframe to the PCs on their desks, which is wonderful, except that at 1200 baud, it can take a very long time.

REVIEW: It does.

TESLER: There are a lot of things being done about that. One approach is background downloading. That’s what is done in Top-View, for example. Another way to do it, which is an approach we’re more interested in at Apple, is to do intelligent downloading. If you think about it, your personal computer has a lot less memory than your mainframe. So why bring down a lot of data from the mainframe? Probably because you want to look at it. But you can’t look at a lot of data at the same time. Your screen is only a few inches by a few inches. You’re either plotting a few numbers or looking at a table, or something like that. It can’t be more than, say, a few thousand characters. At 1200 baud, that takes only a few seconds. So why are people taking minutes and hours to download files? Because they’re bringing up stuff they don’t need to look at right now.

Intelligent downloading is a matter of having the mainframe or the server hold onto the data until it’s actually needed. And then, even at 1200 baud (which will hopefully go up to 4800 baud soon), you can get that data over. Of course, using a local area network, you can get things at much faster rates. On Appletalk, for instance, you can obtain data at a quarter of a million baud, so the problem is a lot less aggravated, but it still exists.

REVIEW: What's being done to improve that situation? Selective menus, for example?

TESLER: No. Let’s say I have a large mailing list on the server. One thing I could do is transfer the whole thing over to my workstation and then scroll through it. The other thing I could do is transfer the first 20 addresses over to my workstation and just display those. As I start to scroll and get to the point where I need some more addresses, the workstation could then send a message automatically to the server asking for more: the user doesn’t have to do anything—he just keeps on scrolling. This is really a software function. It results from software being smart enough to ask for the data when it needs it.

As another example, let’s say you want to produce a chart. Instead of bringing all the data over and crunching it down to some small amount on the PC, you can get the server to crunch the data for you and then send only those numbers you’re going to plot. Servers and mainframes are great at computing numbers and dealing with large amounts of data. Personal computers are great at plotting numbers. So why not let each system do what it’s best at? Of course, the other way to solve the problem is to make personal computers bigger and faster, and that is happening. Five years from now, my comments here might sound ridiculous, because we may have trillion-byte disk drives on every personal computer by then.

REVIEW: But they will be expensive.

TESLER: Well, costs are coming down. But in any event, at some point these comments may seem to be ridiculous. For the moment, though, the issue is intelligent downloading versus background downloading. Both have value. Our future research at Apple is involved more in intelligent downloading. There’s an analog in printing. Instead of shipping bitmap images over networks to print on our laser printer, we send an encoded representation of the printed page, called a PostScript specification, which can be hundreds of times smaller than the number of bits needed to represent the document. This is an example of intelligent uploading. You can encode a document in such a way that very little information has to travel. As a result, communications take less time and place less strain on the network.

This accomplishes two things. We’re cutting down the load on the network, which means you can either use a cheaper network or you can have more people on the network doing more things with it. We're also cutting down the users' waiting time. But if they just do background downloading, then they can't work on their data until it has arrived...ing, they can start work on it right away. You’re taking maximum advantage of the UNIX server’s multitasking, as well as maximum advantage of the intelligent workstation’s dedication to the user.

REVIEW: Another feature that might bring more people into OA is voice.

TESLER: I think voice input to computers is important, but not for office automation. I think it’s important for home computing. Let’s say you’re at home reading a newspaper. Wouldn’t it be nice to say, “Turn off the light and turn off the coffee pot,” so that you could remain seated? When you're at home, there are very few people so there’s not usually a lot of ambient noise, unless the television is blaring. If the television is blaring, voice is useless in the home too—at least until we get much better signal processing. If...the best way to communicate with it is to talk to it. But in an office you tend to be close enough to your computer to touch it. If you’re not, you’ll probably be close to other people’s computers. So if you talk to your computer, all those other computers will hear you too. And there’s a lot of other noise in many offices.

If you have a private office, voice makes more sense. I can see voice being used by the executive who has his own office, doesn’t like to type, is working on a plan for something, and has both hands occupied, with papers all over his desk. This fellow can say, “Get me the last quarter’s financial results,” without having to move his hands over to the keyboard. That’s where voice will have a role in business. But when I think of office automation, I think of rooms full of people with terminals everywhere. I just don’t see how voice can be a great help there. You’d have to have a little headphone. Also, people tire of talking all day.

REVIEW: You'd certainly have cross-talk and you'd have to deal with a certain shyness that comes with not getting a verbal response.

TESLER: Yes. I think it’s a bit weird to talk to computers, personally.

REVIEW: So voice becomes a luxury or specialty item?

TESLER: I think it will be a special form of input. Eventually, voice recognition may be at the stage where you can have eight people talking together in a room because you'll have a microphone that’s capable of sorting out all the voices. Before that happens, though signal processing will have to reach a point where voices can be seperated from each other. Our ears can do that—so why not...

Share

Leave a comment

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.