Recently, the Computer History Museum has uploaded on its YouTube channel a lecture called Origins of the Apple human interface, delivered by Larry Tesler and Chris Espinosa. The lecture was held at the Computer History Museum in Mountain View, California, on October 28, 1997.

Being extremely interested in the subject myself, and seeing how apparently little thought is being given today to the subject, I wanted to quote a few selected excerpts from the talk, just to show what kind of hard work creating a user interface was back in the day when the Apple Lisa was being developed. It turns out that isolating this or that bit was futile, as the whole talk is made up of such cohesive, engrossing discourse. So I chose to transcribe it almost entirely, and add a few personal remarks here and there. I hope this turns out to be as interesting to you as it was to me.

A note on the images used to illustrate the Lisa interface

At first I wanted to accompany the transcription with screenshots taken directly from the YouTube video, but given the overall poor image quality, I tried looking online for the same images Larry Tesler used for the lecture. I found a good approximation in a series of screenshots — actually photos of the screen — taken by Bill Atkinson and featured in four separate galleries published in 2009 by CNET to celebrate thirty years of the Macintosh:

1. Evolution of the Mac interface
2. Apple’s radical UI shift
3. A look at the Lisa desktop
4. Sketching out the Mac

Here is CNET’s disclaimer: The photos were published by another Mac pioneer, Andy Hertzfeld, in his book, “Revolution in the Valley: The Insanely Great Story of How the Mac Was Made.” Through Hertzfeld, Atkinson gave CNET News.com permission to republish them.

I haven’t obtained explicit permission to republish them, but I dearly hope mine will be considered ‘fair use’ given the educational context.

Conventions used in my transcription

• When you see regular text in black colour, it’s either Larry Tesler or Chris Espinosa talking.
• Regular text in square brackets — [like this] — means something I’ve added in the process of adapting the spoken word to the written text to make a sentence more understandable. Or less ambiguous when the person is implying something or referring to something previously mentioned.
• My remarks, observations or integrations are written [in blue text in square brackets]. (This formatting will be lost if you’re reading this text using the Reader feature of your browser. My comments will simply appear as regular text in brackets.)
• Remarks and observations by Tesler and Espinosa which I have found of particular interest are highlighted in green, like this. (If you’re reading this text using the Reader feature of your browser, they will appear as underlined text.)
• To avoid presenting a monolithic wall of text, I have tried to divide the transcription in sections based on what Tesler and Espinosa were talking about, and gave titles to the various sections accordingly.
• Every now and then you’ll notice timestamps in square brackets — e.g. [21:35] — which you can use as reference if you want to follow a particular section on the YouTube video of the lecture. This is especially useful in the first part of the lecture, as Larry Tesler goes through a fair amount of slides.

Thank you for reading!
—RM

---

 

Introduction — Larry Tesler came to Apple from Xerox PARC back in 1980. He figured he was bringing a lot of user interface knowledge with him, only he’s found out recently that user interface testing and development existed at Apple before 1980, and Chris Espinosa had a part in that.

[Xerox PARC: Wikipedia entry | Current website]

Part 1: Larry Tesler

BYTE Magazine Cover — August 1981, The Smalltalk Issue.

[08:00] The reason I show it is that there was a lot of influence from Xerox (obviously) on the user interfaces that were done on the Lisa and the Macintosh — but maybe not as much as some people think. Media tends to just say, Oh, they just copied it. So I’m gonna show you what it looked like to be working on Smalltalk at that time (1981), and you see what the windows look like:

• Little rectangular title;
• Scroll bar without any arrows;
• Two pop-up menus that you could use for each window.

It was a pretty different-looking interface.

[9:54] The idea of the Lisa was to have something that was very very easy to use. People loved the Apple II, which was what we had at the time at Apple, but it took a long time to learn how to use it.

[Larry Tesler shows a study they did, and it illustrates how people learnt the basics of using Lisa applications, like LisaGraph, LisaList, and LisaWrite, in under twenty minutes.]

The Lisa was extremely easy [to operate], in many ways more bulletproof than the Mac — simpler than the Mac, actually.

[Larry Tesler started at Apple on 17 July 1980.] One thing I was told the day I got there was that the user interface design was basically done, and they were just going to write it up, finalise it, and implement it. And this was the 18th [of July], and they told me that all the decisions had to be made by the 23rd, and by one week later the ‘external reference specification’ had to be done, which was the complete spec, but we couldn’t compromise quality at all. And so [they asked me] what could I do between the 18th and the 23rd to make sure we made all the right decisions.

So I started explaining how it was necessary to do months of user testing and careful iteration, and I gave my whole spiel about the right way to design software. And they said, Well, sorry, we only have five days into the weekend in there. So we came up with an aggressive schedule.

[12:52] [Larry Tesler humorously illustrates the detailed — and definitely busy — schedule for 21–22 July 1980. And they actually managed to stick to it.] I think we did some things right. Bill Atkinson started out by talking about who is the customer, so it wasn’t just some easy-to-use computer, it was an easy-to-use computer for specific people. So what was it? First of all, it’s “a single-user workstation designed to enrich the productivity of the office workers” — so our market was office workers. The Lisa wasn’t intended to run thousands of applications.

Integration

John Couch, who was in charge of the Lisa project […] said, All I want is… to be able to go into a spreadsheet, put some numbers in, go and graph them, take the graph, put it into my word processor document, and include it in a report. He said, If I can do all those things in an integrated way, then we’ll be way ahead of anything available on the Apple II, where there are all these separate programs that don’t interact with each other.

That’s all he wanted. Whenever we brought him any issue, he said, Remember what I want, and he went through the whole mantra; and that was a very healthy thing: it kept us focused, and then we also knew when we were done.

Who are the users? Non-technical, non-analytical people. First-time users. In 1980 there were a lot of first-time users. Examples: administrative assistants and secretaries. Secondarily, managers, accountants, and executives. It wasn’t for programmers, it wasn’t for kids, it wasn’t for people at home doing recipes. The Lisa was an office system. So when you compare it with e.g. the Mac, you’ll see some differences based on that, and you may see some similarities to Windows.

Design philosophy

[18:20] There was a whole section on the Design philosophy and what were the most important features to put in.

• Graphic images (I was pretty vague)
• Menus
• A pointing device (“Enables freehand cursor control and invocation of menu commands”)
• Commands may be invoked from the keyboard. Because there were times when you would do things over and over, and people felt that sometimes the mouse slowed you down a bit.

[…]

Mouse

Here’s how the mouse was used. Well, actually they didn’t know a lot of how the mouse was used yet. They mostly were focused on the window manager, i.e. how the user would manage the windows on what we now call the Desktop. And so at the time the idea was this: there would be a click and a drag, and those are two things you could do — you could click and let go, or you could click, hold, drag the mouse and let go.

The mouse buttons got names: the point button and the grow button. [20:44] Depending on where you pointed and whether you clicked or dragged, and which button you used, this page here shows what happens if you went into the title tab of a window, and it either would display the window menu, move the window, open/close the window, or change the size of the window. All of it done by clicking in the title; so there was no grow box in the lower right [corner]. There were no menus — it was all done with just one or two mouse buttons and a click or drag operation.

Now, there was a menu at the bottom of the window, but it had nothing to do with window operations; it had to do with operating on the content inside the window.

Window interface

 

[21:35] As you see, this scroll bar was on the left side, it had the horizontal scrolling arrows at the top, and the vertical scrolling arrows at the bottom. At the bottom, the EDIT menu had CUT, PASTE, DUP (to copy things), and UNDO. And then on the side there were the equivalents of today’s icons; this was taken from Smalltalk, where you took the tab of a window, threw away the window, and just kept the tab (called ‘collapsing’ the window). And these were windows that were available but closed right now, and you could open them up.

[23:00] Scroll bars — You would hold a button down to scroll continuously. Now, there was an interesting idea where you could double-click to flip to the next page. […] Then there was something called the elevator shaft, with the ‘elevator’ in it, and that was what is still today: that little box in the scroll bar. […]

[This is an incredibly effective way to describe this UI element.]

And then there was something called the System Error window — that’s what you know now as alert boxes in Mac and Windows. These would come up when there was a problem, and it would make some kind of ‘beep’, and it would tell you what the problem was.

[By the way, the Lisa’s error messages were much more informative than what other operating systems did. See my article Communication with the User: some examples from the Lisa.]

[24:55] So this is what [the user interface] looked like. The basic model was overlapping windows, which is straight from Smalltalk. There was that box at the top, the Title bar, just like in Smalltalk. The scroll bar was on the left, just like in Smalltalk; only instead of just that little box there were the scroll arrows. We thought it would be nice to have something to point to. In Smalltalk you pushed the button and then the arrows appeared, and we thought that that was a little weird.

And there was this menu at the bottom, and — who’s ever used a system called UCSD Pascal? — if you remember, there were menus in UCSD Pascal, and you would type the first letter of the menu name and it would bring up a submenu; and then you typed the first letter of a menu name and you’d go through a hierarchy of menus, etc. There was an HP computer, HP-something-thousand [He doesn’t remember the specific model] that had a row of function keys on the top of the keyboard and at the bottom of the screen under each key… you hit that key and that would activate the menu item.

Those were the two products that the authors of this interface knew the best. They used UCSD Pascal to do software development; half of them came from Hewlett-Packard, and so this was kind of a blend. So that’s where [the user interface] was in August 1980.

CUT and PASTE were two of the commands in the menu that came from Smalltalk and, as you see, there was a Waste Basket. That’s what you’d call the Clipboard today; we used to call it the Waste Basket, different from the Trash can, which was a confusion we had later and that’s why we changed the name.

[26:43] But when you cut something and, like in the office, [when] you cut something you throw it in the waste basket — but then you could take it and paste it somewhere else… (It was a weak metaphor)… and so you’d select it with the mouse. Notice that when you select it, there’s this little arrow here that turns out to be a significant point later.

Ken Victor was one of the reviewers of the document and he provided some input very very quickly. He said, Why can you only select it with the mouse? He must [have been] someone who used Emacs or something: he wanted you to be able to select from the keyboard. You know, fourth line, third word, seventh character. You should be able to specify what you want, like fourth occurrence of the word “Lisa”, things like that. And he sort of didn’t get it or he was years ahead of his time. […] We had to explain to him that our target market didn’t want to find the fourth occurrence of the word “Lisa” in the third paragraph — they could see it with their own eyes and select it with the mouse, and that was just fine.

Now here was something I wish we’d listened to: at this point it said that you were growing windows from the lower right. Now, I showed you something before showing that you grew it at the top… I think in this document it was sort of ambiguous whether you grew it [the window] from the top or the lower right, and he [Ken Victor] didn’t like the idea: he wanted to be able to grow the window from any side, and I do think that’s better(*), and we didn’t pay attention to him. I think we were worried about the screen space being too tight or something.

[* This has been implemented in Mac OS X only recently, by the way.]

Moving a document within a window, [Ken] wanted to know whether we could do what we now call live scrolling — as you move that elevator up and down the shaft, he wanted the text to move continuously. The problem was that the Lisa processor couldn’t do it. Not fast enough.

So, some things were just pragmatic: he didn’t like the idea of CUT and PASTE; he wanted us to use MOVE, COPY and DELETE — and TRANSPOSE: in other words you would select [and then] move this to there, copy this to there, transpose these two things… Well, this wasn’t the first time I heard that argument, and in fact this is one of those religious arguments like one button versus two buttons [in a mouse].

[…] The reason we [preferred CUT/COPY/PASTE over MOVE/COPY/DELETE] is that [while] it is two steps to do CUT and PASTE, there are a lot of advantages. […] Another reason is that you don’t have to be able to see the destination when you are copying or cutting the source. That’s the most important thing. And on a screen of limited size, when you have windows overlapping, it’s sometimes very hard to get things all lined up so you can specify two targets; or you have windows popping up and down, and you get very confused.

The other thing is that I had a secret agenda: I thought that the machine should be used not for what they talked about (office systems) — well, that was good, but I didn’t want it to be used just for that. I thought it would be a great machine for publishing and that it would be able to do cut & paste into page layouts, which was my own personal interest; and so I was advocating that because that was definitely the way you’d want to do page makeup. But we did user testing, and the users slightly preferred the CUT and PASTE model.

The Waste Basket window was able to not only have one thing you cut out, but multiple things you cut out, and [Ken Victor] had some comments about how they deal with multiple items. Some of us thought it should only hold one; he thought it was okay to have multiple ones. He lost in the end.

[Which is a pity. This is essentially like having multiple clipboards built in the system. Maybe if they had figured out a way to make that work on the Lisa, the feature could have been transferred to the Macintosh as well. Today Mac OS still doesn’t have built-in multiple clipboards.]

Another interesting question was: Well, we want keyboard-accessible commands, so we seem to be fixated on the way they do it in UCSD Pascal — you type a key, you get another menu; you type a key, get another menu, etc. And that bothered me. I thought that a lot of mistakes could be made: people are gonna forget which level of the hierarchy they’re in: how do they get back out of it again? It’s just gonna be too complicated, and I didn’t like it. (We’ll come to how that was solved later).

[31:32] The other thing I was complaining about was the two-button mouse. We didn’t use the second button for much else, and when we did there was no way to remember which button did what, and so I just wanted to eject the second button and just have one.

Operations on windows

I proposed here that we have this box in the lower right-hand corner [of the window] that we use for growing the window, instead of doing it from the top.

[Another element that’s been a part of the Mac user interface for years. I also find it interesting how Tesler says ‘to grow the window’ instead of ‘to resize the window’.]

And also I thought there ought to be a way to split a window into panes. Those of you who know the Xerox Star know that the Xerox Star had that feature [Larry Tesler explains that he proposed and prototyped having one arrow at the top of the scroll bar and one at the bottom of the scroll bar.] But those of us who were from Xerox were under a confidentiality agreement, and we weren’t allowed to tell the other Apple people about the Star; and so, as you go through this, you’ll sometimes wonder: Isn’t this an obvious solution? You could have got it from the Star. But none of us were able to say how the Star was [and worked]. We were only able to comment on other people’s proposals and make new ones. But then gradually, over time, a few Star-like things crept in — but not many — until the Star actually shipped or was announced in June 1981.

Then I suggested we try an I‑shaped cursor for text selection instead of an arrow, and that actually is something I had done in my early years at Xerox in a particular word processor I’d done. I also said I wish the cursor would be bigger than 16×16, [I wish it would] go to 32×32, which we eventually did.

[33:34] Menus — [Larry Tesler reads] “I think we should experiment with menus at the top or right of the window, or even totally detached at the top of the screen, full width.” So, up to this time we were doing sort of the way Windows does, where every window had its own menu. And I was thinking, You know, maybe we got to put it at the top, and you’ll see why in a minute when you see the pictures. And then I said: “Hierarchical menus? Well, maybe we have to have them, we can’t get rid of them — but could we make a mouse access instead of having to type all these keystrokes?” So these were my two causes of the moment.

Barry Smith, who was in product marketing, responded [at] about the same time. At this point, Bill [Atkinson] had moved the menu bar (with EDIT, CUT, COPY, PASTE) from the bottom of the window to the top of the window, and Barry liked that change. And then [Barry] wanted to know though what would happen if there were a lot of menu items, and [asked] “Could the menu scroll?” Those of you who know the history of the Mac user interface know that at some point (I don’t know — 1990 or so) we started adding scrolling to Mac menus, but we didn’t have them in the early Mac and in the Lisa, and I was against it because that would have encouraged people to have a lot of menu items, and I didn’t think they should, so I kept that from happening. (You can’t constrain people, though).

[I love these observations. Here, Larry Tesler’s choice and reasoning doesn’t strike me as a merely cosmetic choice. It’s not that he didn’t want fewer menu items because the user interface would have looked ‘prettier’. From what I understand, he didn’t want a lot of menu items because he wanted simplicity and intuitiveness in the user interface. Too many menu items and scrolling menus would have added complexity to the user interface.]

Barry also didn’t like the fact that you had to type multiple keystrokes through a hierarchical menu, and so he was thinking, Maybe we could get to something where it was a single keystroke to invoke a command, no matter where it was in the hierarchy. And he also didn’t like the two-button mouse: he thought it was confusing.

Towards a one-button mouse

18 August 1980. A few days later, after intense political polite discussions (heated sometimes), Bill [Atkinson] and I decided: Hey, let’s get rid of the second mouse button. We wrote the memo together and we said “We recommend a change to a one-button mouse.” Someone didn’t agree. But Trip Hawkins (the Product Marketing manager) loved it. He said, That’s what we got to do, we should be more consumer-oriented, keep things simple, get rid of all these ‘computer science’ concepts, etc.

[36:26] If you only have one button, some things are hard to do: you can drag a short selection, but what if you want to select something [that’s] three pages long? It’s a long time to drag from one end to the other. So we thought — Okay, we’ll use the Shift key on the keyboard, since this doesn’t happen very often. You’ll click the beginning of the selection, you’ll scroll to where you want to go, you hold down the Shift key and click the end of the selection.

[This procedure is still in use today.]

[36:55] “The one-button mouse is superior” — And then we said: “The one-button mouse is superior. Look at the reasons:

• You don’t have to think of a name for each button! [laughter] That’s important when you’re trying to ship products in six months!
• The mouse will be cheaper to make because… one less button! I mean, just think of the cost of those little switches!
• And then something more profound: someday, when we start having other things than mice on our computers, like joysticks for games, tablets, touch screens, we’ll be glad we only had one button, because that one finger, or pen, or whatever the user is using is the button. And that turned out to be sort of prophetic. (Although very few of such pointing devices take advantage of that; in fact, they usually have buttons anyway.)

[Sort of prophetic indeed.]

Revised version of the user interface

[37:41] August 22nd. At this point we were working on this interface for a month already. This version had a concept called Dim highlighting. It was introduced here for the first time (that I know of). Instead of eliminating menu items that weren’t relevant, we would dim them, we would grey them out — instead of being in black type, they would be in grey type. And then we said: “They can be invoked anyway if the user wishes, although they wouldn’t do anything.”

We were also going to use dim highlighting for another purpose: to show toggles. And as you know, that was later changed to have checkmarks (✓) instead of just using this [dim highlighting] for two purposes, because that was very confusing.

Brief interpolation on keyboard shortcuts — Now, as you know, you can do command keys [command key combinations] on the Mac; you can invoke commands from the keyboard, and we knew it was important to reserve some for the most common commands. […] We wanted to make sure that CUT, COPY, PASTE, UNDO were the same for everybody. [Same for] BOLD, ITALIC, UNDERLINE, and NORMAL.

Why the Z X C V keys? — They were close on the keyboard. We did X because it was a cross out (CUT). We did V because it pointed down like this [he makes a ‘V’ shape with his hands], and you were inserting; it was like an upside-down caret (PASTE). And Z was the closest one, because we figured you’d UNDO a lot. And C for COPY — that was easy.

Windows and menus

[40:18] Okay, so this was the anatomy of a window. We had the Title tab, and notice next to the Title tab we now moved the menu (bar) to the top […] and look, there are menus that are popping down from the menu bar for the first time. When the menu bar was at the bottom, it didn’t make a lot of sense, but now that it was at the top, instead of having the menu come here and replace the previous menu like it did in UCSD Pascal, Bill [Atkinson] could use the second dimension and have a menu pop out to the bottom.

Don’t ask us how we were gonna do third-level menus but, at this point, this was good enough. We had two levels of menus and we were happy.

We had continuous scrolling arrows — and notice the arrows point this way [he taps on each up/down arrow] but when you clicked on these arrows, the text was going to move that way as opposed to the other way, which is what it does now. And that was an interesting argument that I think I have covered here too.

[Larry Tesler is saying that at this stage of development of the Lisa interface, when you clicked on, e.g., the upward-facing arrow, the content would move upwards too, in the same way “Natural scroll direction” works since its introduction in Mac OS X 10.7 Lion. But at the time of the lecture — 1997 — the established way of scrolling text and content in a window was that when you clicked the upward-facing arrow, the content would move downwards. This was what has felt ‘natural’ for decades, really.]

 

[41:30] We had active folders, so we had to have passive folders. Now, look at the bottom: who has ever seen Mac OS 8? When you drag a window to the bottom of the screen it just kind of pops and becomes just a tab, and then you can click it and it’ll slide open. Guess what? That was in the original design in August 1980 that we were going to do on the Lisa, and it only took 17 years to implement (!) […]

[If you don’t know what Larry Tesler is talking about, here’s a handy quote from The Mac OS 8 Book, by Craig Danuloff and Mark R. Bell, 1997, page 55:

In addition to viewing the contents of a folder or hard drive as icons, buttons, or lists, Mac OS 8 introduces yet another way to view folders and their contents: the pop-up window, three of which are shown in Figure 3–8 (two minimized and one opened). When a folder is dragged to the bottom of the screen, it turns into a tabbed pop-up window, only one of which is able to “pop up” at a time. You can resize the window or “bring it back” as a normal window by lifting it up or out with the resizing corners on either side.]

 

 

[42:00] Now, what happened if the window was narrow? Well, this shows that the menu wouldn’t fit; it would stick out. And if it was over on the right, [the menu] couldn’t stick out to the right, it would stick out to the left. And if it was too close to the bottom of the screen, then it would do this [See video at 42:18]. And so Bill [Atkinson] showed all the cases, and a lot of us weren’t too happy with this. So I went back to Bill again and I said, Bill, the top of the screen… the top of the screen!

None of us liked the idea of a two-lane menu, which is the way Microsoft solved it in some version of Windows. And here’s an example of a menu item being selected [42:39]: notice it’s now got highlighting of the menu title, and it’s got highlighting of the menu item (Bill had a long night that night, and came back with that), and we had the HELP menu in here. [In the EDIT menu. The menu items are CUT, PASTE, COPY, UNDO, and HELP. See image above.]

The way we operated was that Bill spent every night programming, and the next day we would do testing and arguing. I don’t know when he slept, actually. (Did he sleep?) And then he would do it [over] again every night.

[43:00] Now here’s a memo from Gail Pilkington in Publications. The people writing manuals for the Lisa were key in commenting on the user interface design, they had a lot of suggestions and a lot of good criticisms. And Gail actually had been at Xerox before. So she said, I don’t like pull-down menus. I think they’re ugly and they cover things up. So, you know, I’m trying to cut something and the first thing that happens is the menu comes down and it covers the thing I’m trying to cut. Not good.

And then Bill had this feature, that you could drag the mouse along the menu bar, and the menus would pop up one at a time. [This feature is still in Mac OS today, of course.] And we thought, This is great: the user can see all the available commands in one swoop. Well, Gail thought it was terrible that you had to do that to see all the commands. I didn’t understand, because in UCSD Pascal you had to hit keys for like ten minutes to see all the commands, so I didn’t quite get that [Gail’s criticism]. She also didn’t like the idea of dim highlighting: she thought we should just suppress the [menu] items altogether. So… we had dissent in the group. […]

[44:41] 22 September 1980. It was now a month after I first said, Bill, why not try at the top of the screen? [for the menu bar]. Bill had a very long night and came back with a menu at the top of the screen with command keys [shortcuts], checkmarks, everything… In one night he invented the entire mechanism of the menu bar at the top of the screen. To me it was just a place to put what we already had, but once Bill realised it was there, he could do a lot of things, and he implemented an amazing amount [of things] in one night.

So he wrote a memo to justify it, and said, There are some problems with it. You have to go way further to reach the menu, but we decided since there were command keys (he made it very easy to have a single-stroke command key [shortcut] in this version), we decided that, okay, if you really wanted to go to that menu item a lot, you could hit the command key [shortcut] on the keyboard instead, and you wouldn’t move the mouse at all. So that solved that problem.

The other problem was that if there were a lot of windows open, you would not really be sure which menu applies to which window — and sure enough, that’s still true today. But trade-offs, you know.

Why was it good? It was good because you got rid of all those ugly cases of sticking-out menus; and also the dialog box that came up when you had a command with parameters could always go in the same place. We had a problem before with the dialog box coming up and covering up the menu, half the window, and so on. And so we could put it in a standard place under the menu bar.

A couple more examples: we could put some global commands in the menu. Before we hadn’t figured out yet where to put the global commands; they didn’t really go anywhere because every menu was in a window. But now, having a menu at the top, we could have global commands like Shutting down, etc. And then we could widen the tabs because the menu didn’t take up room at the top of the window.

Guidelines for user testing

[46:40] February 1981 — Programmers are busy implementing stuff, they’re designing an operating system [and] telling us that we’re holding up the project when they’re still designing the operating system. Yes, I was in charge of the Applications group, and we were the reason the project was behind schedule. I wrote a memo for other people who were going to help out with user testing, and I made guidelines for user interviews:

• Never argue with each other in front of the interviewee.
• Don’t patronise a subject, don’t show off your knowledge. I wrote this because I would be bringing engineers into the room and I’d sit them in the back, and the user would struggle to do something, and the engineer would jump out of the chair, run forward, grab the hand of the person and say “It’s easy! You just do this!” And I’d go: “No, no, no, you don’t get it.”
• Don’t plant the answer, take turns asking questions. This isn’t a lecture by you, this is a test of them [the users], and you want them to verbalise all that they possibly can.

The difficult thing that would happen is we bring somebody in to prove that the user-interface thing they put in was absolutely right and we were totally wrong, and then the end user would usually prove we were both wrong. Both our things were hard to use and then we’d have to go back and redesign it. Or half the time the user would say, Well, why doesn’t it just work this way? — and we would look at each other sheepishly and fix it. [In case it wasn’t clear, in this context ‘we’ is Tesler’s group and the user-interface designers in general, while ‘they’ are the engineers and programmers.]

[49:46] 3 April 1981 — At this point they’re starting to get very nervous about the schedule. The operating system design was done, I think. And so we were holding things up. They decided the problem was that these engineers, instead of writing code like good sheep, were worrying about whether it was usable or not, so they decided to take all power away from us and put all the decision-making into a council. [While here I think ‘they’ refers to Apple’s executives.]

So, who was on the council?

• The first person was the division controller in Finance (Jennifer Bestor).
• The second one was the VP of Sales (Gene Carter), who was always on the airplanes.
• The third one was the Head of Publications for Lisa (Nellie Connors), which was a good idea.
• The fourth one was kind of the architect of the Group (Bruce Daniels) — that was a good idea.
• And the fifth one was somebody in Product Marketing (Barry Smith) who, as we saw, had made comments before that were pretty good.

So, I was looking at this and going, Hmmm, okay, maybe we can live with this. But the main thing they did that was very good was to institute a process for what to do if you had a user interface issue: Don’t spend eight hours arguing with each other; write it up, make your points, get back to work, and then we have a process for dealing with it. But the council will rule by majority vote. So I think, What a way to design a user interface… By majority vote of the controller, the Sales VP…

[laughter]

[Tesler’s remark is so spot-on, and sadly the results of a similar way to proceed — the infamous ‘design by committee’ — are visible today in many products and user interface design… If it still can be called user interface design, for that matter.]

But this motivated those of us who decided we had to do this the right way, to actually run more user tests. As we thought, Maybe we can overwhelm them with facts, and that’ll overcome this reliance on votes of committees.

[Larry Tesler here gets into some details about user testing. I’ll skip this part but you can follow it in the video from about 51:18 to 54:45. Here are some bits worth mentioning, though:]

[54:32] [Wallace Judd] wrote this memo about some testing results, and he said he spent an hour [per] subject […] and he said, Well, some functions were still unclear. In particular, seven subjects out of… — how many he doesn’t say — most of the subjects had trouble with UNDO LAST COMMAND. They’ve never seen such a thing in a program before, and they just didn’t quite understand what it meant.

Then there were other ones they understood but they didn’t feel comfortable with somehow. One was PRINT A COPY, one was MAIL A COPY. Well, I believe the reason was that we didn’t have printers yet on the machine, and we didn’t have email. In fact, we never had email, so we were probably just showing these and [people] couldn’t use them, and so of course they didn’t understand them.

Graphic editor user testing

[55:28] This was LisaDraw, which became MacDraw later, implemented by the same guy, Mark Cutter. We wanted to test a few things:

• Is that confusing?
• What happens if you try to use rulers at the same time as crosshairs?
• Are there too many things on the screen?

(And considering all the widgets that are there today in [a program like] Photoshop or something, why were we worried?) There was even worry about whether people could use a graphics program because, well, you know, most people can’t draw, so they wouldn’t use a graphics program.

We also wanted to know the error rates, and so a lot of counting was being done, and looking at the tapes to see how many times people made errors, [to] try to reduce the error rate.

So we’re trying to be sort of scientific even though we were on this headlong schedule. You may have noticed that six months have already gone by and we haven’t shipped. In fact, it’s about a year at this point.

[56:26] June 1981 — Pat Marriott writes this memo about validating the prototypes, and Trip Hawkins is at his wits’ end; he says, Aren’t we done with all these decisions yet? Let’s get on with it — why are we still talking?

Okay, here are some of the issues. Should the arrows point apart away from each other, or towards each other? Because, after all, the text moves in the direction that’s opposite of the arrow direction. We could flip the arrows and make them point to each other. I wrote up a comment here: “Yeah, we can wait till September to test this, no hurry.” I wasn’t in sync with Product Marketing [people] who wanted all the decisions to be made, because I knew that changing this was a matter of three minutes of programming, so what was the hurry? I’d rather work on harder issues like, you know, getting the software to fit in memory!

[57:50] October 1981 — We did outside testing: 24 people who did not work for Apple [were put] in a one-way mirror room. They didn’t know what company it was. You know, blind testing.

We wanted to know whether they could read the manual and install the hardware and get the thing running by themselves. And it turned out it was 10 minutes on average from they trying to open the box till the time they get set up and running something. We thought that was pretty good.

Those of you who were at Apple later know that on the Mac it was even easier at the beginning, but as the Mac got more and more developed, that number went up, and when that number started getting to about an hour, Jean-Louis Gassée got extremely upset and he ordered new user tests; and they ran user tests about that, and got the time back to 10 minutes again. But there were some bad years in there. It was very hard to open a Mac box and figure out how to set it up.

[From about 59:07 to 1:01:38, Larry Tesler talks more about user testing and the implementation of a more formal method of testing. There was also a new process for approving the work on the user interface. Instead of the council mentioned previously, now they were going to have “People with authority, people with responsibilities, people who are consulted, people who are informed, and basically Product Management had all the authority […] So we did all the work and then Product Management would bless it.”]

[1:01:40] And by the way, the thing that went over the Product Marketing people was when we gave them the drawing program [LisaDraw]. It was the first one to get working. I had Mark Cutter just try to get it really reliable and not worry about too many features. And then we gave all the Product Marketing people a Lisa, some temporary operating system, and the drawing program — that’s it. (A single-tasking operating system at that time). They all started using it to make foils(*), and you could do text, you could do boxes, and they all did foils; they fell in love with the Lisa, and they even started to understand the Lisa. Gradually the complaints started dying down and they started trusting [that] maybe we knew what we were talking about.

[* I’ve listened to this bit many times and I’m pretty sure Tesler says ‘foils’, and I guess he’s using the term in its architecture-related meaning of “a leaf-shaped curve formed by the cusping of an arch or circle” — But I welcome any correction from native English speakers. Update: I was contacted by several people about this, and the consensus is that Tesler is referring to transparencies, “thin sheets of transparent flexible material, typically cellulose acetate, onto which figures can be drawn. These are then placed on an overhead projector for display to an audience.” (Source: Wikipedia)]

So that was a very good political move. And I always made sure Mark [Cutter] gave them good, stable versions of the Draw program. […] People were basically really positive about this program.

Now, this particular test was (I guess) run by Greg Stikeleather and me.

[In the early 1980s, Greg Stikeleather worked as an instructional designer for Apple Computer, where he developed and ran the first usability testing lab, when Apple’s goal was to get novice users up and going in 20 minutes or less using a new, graphical user interface. Mr. Stikeleather was trained in the learning sciences with an undergraduate degree in behavior analysis from Western Michigan University and a graduate degree from Northeastern University in experimental psychology. — Source]

He made a comment which was that when the person started typing, the ‘I‑beam’ (the cursor that you used to select text) was covering what they were typing. So he suggested that we get rid of it. Well, there was no mechanism to get rid of it in the software, but he didn’t know that. So it was good that he was there and suggested it, and we then implemented that [behaviour]. [It still works this way on Mac OS today. When you hover the mouse over text, the pointer becomes an I‑beam cursor, which disappears as soon as you start typing.]

I pointed out that the stretch handles were a problem. Initially, Mark [Cutter] studded the outside of your object, like every fourth pixel, with a little handle, so big objects had — you know — beads all the way around the outside; it was like a necklace, and this really confused people. I suggested we just had the four corners and the four sides, and that is the way it ended up.

Development tests, and more user interface issues

[1:04:14] May 1982 — So Greg [Stikeleather] said we should run development tests, so we did. And I taught 30 Apple employees over a period of several weeks several different applications to see whether we were on the right track. And by this time people were accepting — this was a good approach because it was a lot better to be informed by a user test than to just see who talked the loudest in an argument or who had the most political clout.

And what I found was that the way we taught it made a lot of difference. You could take the same user interface and teach it in a different way, and people would get confused; or understand it; or make more mistakes; or fewer mistakes. And terminology made a difference also, so we then started a terminology project that Ellen Nold ran, which ended up with the FILE menu, the EDIT menu, etc., as you know today, and all the various commands that were in them. You know, choosing all the words for everything. About 95% of them survived into the Mac, and most of them went into Windows also; so that was a very healthy terminology exercise.

We did a lot of testing and a lot of debating, a lot of linguistic analysis. And one thing I’d say here is that after all these tests I discovered a lot of things that could be better, but — we do have to ship a product, and it’s been a long time since I’d been at PARC, so okay, we’ll ship a product. But couldn’t we fix these in the next release? … Well, little did I know… there would be only one more release.

And then we had a process again where we were going to be very careful about prioritising all the user interface changes, and measuring their schedule impact, and being sure they were worth it. Didn’t have to be zero necessarily, but it had to be worth the schedule impact.

I think by this time people were really realising that our only differentiation was ease of use — and it better be really easy. And then I went through some problems — and by the way, this [document] went on for about 30 pages, so I’m just going to show you one page.

Cursor changes were not consistent. There were cursors changing shape everywhere. The I‑beam wasn’t the only one; like, no matter where you went in the window, you got a different cursor shape. And I thought, That’s too many, let’s simplify that.

We had double- and triple-clicks at that time and [for] some people it was the amount of time between clicks what mattered, and you couldn’t control it; so I suggested we had a preference item where people could control that time, which of course is what you do today [1997] in Apple’s Mouse control panel.

And one month earlier, I think, Greg Stikeleather had pointed out that the I‑beam should disappear when you type. I don’t know if I forgot or whatever, but I suggested the same thing again, or observed it, and I proposed we hide the cursor. […]

We were wondering about the cursor changing to a clock or an hourglass and various other things. That was something that was actually at Xerox. Xerox had that at PARC, and the way we did it was we would wait a certain number of seconds, and if the operation wasn’t done we would put up the hourglass. The trouble was [that] by that time the operation was probably done; or some of the applications forgot to put it up at all; so we came up with a clever algorithm for having it come up automatically and disappear at the right time.

Those little icons on the desktop…

[1:07:59] Now here’s the big change: the Star had come out a year earlier than this, and we were all set, we were all told by management and ourselves, Don’t pay any attention to that. We got a product to ship… But in everybody’s heart they kind of felt like, You know, most of the Lisa is easier to use than the Star, but there’s one thing about the Star that is really really nice, which is those little icons on the desktop.

There was icon envy! That was very serious. And we weren’t allowed to work on it, but around March of that year some of the guys got so troubled by it that they started working at home on weekends on an Iconic filer (as we called it). And at first it was a big secret, then they started letting people in on a little bit at a time, and finally everybody found out about it and there was a major uproar — how people would dare to make changes at this late stage! But they’d already implemented it, and so you couldn’t complain about the schedule impact. And the person writing the manual thought it was kind of a good idea, so she kept saying it wouldn’t affect her schedule. And so nobody knew what to do, so I made a deal with Trip Hawkins and Wayne Rosing (who was the Engineering manager at that time): we’ll run user tests and let the users decide.

So I ran tests and, you know what? It turned out that the interface we had was actually equally good in terms of ease of learning, equally easy to use, same error rate (very low), people understood both… [Both the interface with and without icons.] There was no difference! And we already had one [interface], so why did we change? And then the last question I asked everybody was “Which do you like better?” And they all liked the ‘picture one’ better. So we made a decision that had nothing to do with ease of use, nothing to do with ease of learning, nothing to do with error rates. It wasn’t a human factor’s decision at all in the traditional sense. It was a decision based on what customers liked.

There’s a whole history I won’t go into here about the icons. They didn’t actually come from the Star. They came from something IBM did… Long story. You can read the Proceedings of Apple vs Microsoft lawsuit or something, to find that out. [laughter]

So this is my last slide. This was a memo that included on it Chris Espinosa, who was in the Macintosh Group at that time, and the Macintosh people, who had been doing a totally different user interface, at some point decided they really ought to do some subset of Lisa’s user interface instead, and so they wanted to get a lot of ideas from us as they designed their user interface. So we started copying the Mac people on it. And with that — September 1982 — I’ll turn it over to Chris.

 

---

 

Part 2: Chris Espinosa

[1:12:55] As Larry said, the work that we did on the Macintosh human interface dovetailed with the end of the very fruitful period of Lisa human interface design. I cannot believe how much work they went through in a short period of months in the summer of 1980 to put together what we still see today in the human interface of the Macintosh and the human interface of Windows.

But what was really interesting to me was that when Larry first proposed this talk to educate some new people at Apple [coming] from some companies we’d acquired on how the user interface came to be, that a lot of the people he was referring to, a lot of the people who were co-copied on some of the documents, a lot of the work they drew on, really had nothing to do with the graphic user interface. But it had to do with a long-standing user interface community at Apple that had evolved in a totally separate organisation for a totally separate strain. And that was the Apple II and the Apple III human interface effort that was going on in the Personal Computer Systems division, which was by that time physically remote, down in the big black triangle-shaped building at the intersection of 280 and Lawrence Expressway, called the Triangle Building — or, by then, the ‘Bermuda Triangle’, because it’s where the Apple II Group had been moved to die.

[laughter]

The different approaches of the Lisa/Macintosh Groups and the Apple II Group

The thing that you really have to understand about the crucial difference between the Lisa/Macintosh human interface effort and what was going on in the Apple II Group, was not the difference between the graphic human interface and text-based human interface (though that was an important part of it). The crucial difference was that in the Lisa and the Macintosh, the engineering groups were completely integrated in, and [were] the driving forces behind making the computer easier to use.

Whereas in the Apple II the evolution of that had been that the impetus for making the computer easier to use, and which programs were selected to make that, had come from the Publications department, the Training department, and the department doing demonstrations for in-store retail sales. Our effort — I was a member of that group — was primarily to mask the complexity of the real underlying software that we were already shipping, by putting sugared user interfaces on top of the real interface, and by putting training programs on top of the real computer programs.

Remember, Apple Computer by 1980… boy, we’d been around for three years; we had a long history behind us in the personal computer history, and we had a lot of accumulated legacy software that we couldn’t just haphazardly change — we really had to work on it. […]

The Apple II Human Interface Guidelines

[1:16:22] [For the following segment, the document Espinosa refers to — the Apple II Human Interface Guidelines can be found here.]

This is the document, and this is the change history of the Apple II Human Interface Guidelines that shows the first draft Bruce Tognazzini claims to have written in September 1978. Second draft was written in March 1979, third draft in mid-1980, fourth draft with Steve Smith in early 1981; and then it got into the Macintosh Group in 1982. I started working on it in late 1982, and that’s when I incorporated many of the things from the Lisa efforts; and then it moved back over into the Apple II Group to cover the Apple II graphic user interface.

But it originally started as an Apple II text human interface document, and it came originally from Bruce’s efforts with J. D. Eisenberg writing an application called Apple Presents… Apple, which was the main in-store or first user demonstration program for the Apple II.

Bruce started out — well, I don’t know where Bruce started out, but when we encountered Bruce Tognazzini in his long and chequered career, he was the proprietor of a computer store in San Francisco, which is were the Apple CORE [user group] of San Francisco used to meet; and that’s how he got into the Apple community: by selling Apple computers. So he had front-line experience of what happened when a person encountered a personal computer for the first time.

When he came to Apple, he started writing demo programs with J. D. Eisenberg, and one of the things they did was they tested on real users in real situations where you brought somebody who’s never seen a computer before (much like the Lisa Group was testing people off the street, or new employees), put them in front of this program, and gave them no advice whatsoever.

User testing: some observations

[1:18:18] I’m going to read to you some of Bruce’s experiences from user testing.

[Chris Espinosa reads the afore-linked document from page 30:]

Our testing method is as follows: We set up a room with five to six computer systems. We invite groups of five to six users at a time to try out the systems (often without their knowing that it is the software rather than the system that we are testing). We have two of the designers in the room. Any less, and they miss a lot of what is going on. Any more and the users feel as though there is always someone breathing down their necks.

The initial ground rules are that no questions will be answered, as by the time the formal testing begins, we can supply a draft of the manual. (Usually by the second group, some glaring defects in the interface have shown up, and we have to give them help getting past the stumbling blocks.)

95% of the stumbling blocks found are found by watching the body language of the users. Watch for squinting eyes, hunched shoulders, shaking heads, and deep, heart-felt sighs. When a user hits a snag, he will assume it is his fault: he will not report it; he will hide it. Make notes of each problem and where it occurred. Question the users at the end of the secession to explore why the problems occurred. (You will often be surprised at what the user thought the program was doing at the time he got lost.)

[…]

Herein follows a true anecdote which illustrates how difficult the most simple human interface issue can be, and why thorough testing on real people is so important.

As we tune in, the authors of the software, both of whom pride themselves on clever interface design, have anguished for hours over difficult passages in their program. It was to turn out their guesses were quite accurate in said difficult passages. It was the simplest question of all that caused all the problems…

Problem: in Apple Presents… The Apple IIe, the training program for teaching fundamentals of using the new Apple lIe computer, find out if the user is working with a color monitor.

User profile: new owner, customer in a computer store, or member of a class learning to use Apple computers.

Test user profile: customers in a computer store, non-computerists in a classroom environment, friends, and relatives.

First design: A color graphic would be displayed.
Prompt: “Are you using a color TV on the Apple?”
Anticipated problem: Those who were using a monochrome monitor in a classroom or computer store situation wouldn’t know whether the monitor was black-and-white or was color with the color turned off.

 

First attempt: A color graphic was displayed.
Prompt: “Is the picture above in color?”
Failure rate: 25%

Reason: As anticipated, but incorrectly overcome, those seeing black and white thought their color might be turned down. They didn’t answer the question wrong; they turned around and asked one of the authors whether the monitor in question was color or not. A decision was made that the authors could not be supplied with the disk:

 

Second attempt: A smaller graphic with large-letter words in their own vivid colors was substituted: GREEN BLUE ORANGE MAGENTA
Prompt: “Are the words above in color?”
Failure rate:

• • color TV users: none
  • black and white monitor users: none
  • green-screen monitor users: 100%

 

Third attempt: the graphic remained the same.
Prompt: “Are the words above in more than one color?”
Failure rate:

• • color TV users: none
  • black and white monitor users: 16%
  • green-screen monitor users: 50%

Reasons: the black and white monitor users who answered incorrectly admitted that they did so on purpose. (Our methods for wringing their confessions shall remain proprietary.) 50% of the green-screen folk considered that they were looking at both black and green — two colors — and answered the question accordingly.

 

Fourth attempt: Same display of graphic and colored text
Prompt: “Are the words above in several different colors?”
Failure rate:

• • color TV users: none
  • black and white monitor users: 20%
  • green-screen monitor users: 23%

Reasons: By this time, the authors were prepared to supply everyone who bought an Apple with a free color monitor, just so we would not have to ask the question. It turns out that around 20% of the people were not really reading the question. They were responding to:

“Are the words above, several different colors?”

 

Fifth attempt: Same display of graphic and colored text
Prompt: “Do the words above appear in several different colors?”
Failure rate: none.

In case it appears the authors were simply dull fellows, be it known that this was a fully-interactive training program in excess of 100K, and this was the only interface issue that required more than one correction. It clearly exemplifies how even the most careful designers can totally miss when guessing at how users are going to respond.

The interface of the Apple II and the importance of consistency

The Apple II project had started out— well, the Apple II wasn’t really a project, it was a collection of projects… We started out with a number of pieces of software that had our cherished angle-bracket or square-bracket prompts; by the time we got around to the Apple IIe and the Apple III we developed a more-or-less text windowing interface called the Filecard metaphor where we used special characters in the character generator ROM to do something like the Filecard interface in the Lisa: pick 1, 2, 3, 4, 5, 6 menus and you use the Escape key to back out through a hierarchy; and press numbers 1, 2, 3, 4, 5, 6 to advance to the next level. It was a hierarchical spatial text-driven, keyboard-driven, user interface — it didn’t use the mouse. It was very successful for what it did.

We ensured consistency across many applications: all the applications that Apple implemented as well as third-party applications. For example, if anyone was familiar with Quark Catalyst — Quark are the people who make QuarkXPress now; they made the original hard disk manager for the Apple II and the Apple III, and it used the same interface. It had consistent use of the keyboard keys, the Open Apple [key] always meant the same thing in different applications, etc. And so, even though it was a text interface it had many of the underpinnings of the consistency of the graphic user interface of the Macintosh, and it was driven by the exigencies of user training (which was my mother’s group) [Sue Espinosa], because the less time we had to spend on user training, the cheaper and faster it was, and if the software were consistent the training went more easily.

It was driven by the exigencies of Publications (which was the group I was running), and one of the problems we faced in Publications was that having not invented Desktop Publishing yet, we had six weeks minimum from film to printers, which was usually the time that was reserved to write or finish the software. And we often had to be finished with the manuals several months before the product shipped, and the software wasn’t finished at that point.

So, in order to have manuals that accurately reflected what the software was going to do, we had to have the programmers tell us what the user interface was going to be; and then, going through that with the programmers, having them do it the same way that other applications did it, gave us a more full idea for, Okay, it’s going to do this, it’s going to do this, it’s going to do that, if they followed some standard or some guidelines. In fact, what Bruce [Tognazzini] did before writing the Apple II Human Interface Guidelines, and what the origin of this document was, was in fact a Publications’ style guide, which was how we wrote manuals and how we explained portions of how you use the computer. And by using consistent explanation, that drove consistent design in some of the applications.

So that was [some of] the origins of user testing and of consistency of user interface design in the Apple II Group. As I said, it moved into the Lisa Group. [The Lisa Group] started with a separate angle from which Larry [Tesler] talked about coming from the Xerox PARC, and the two basically fused in the Macintosh Group, where we had the benefits of years of Lisa user testing experience and the massive amount of design that went into the graphic user interface, plus a lot of the democratic grass-roots issues that had come up through the Apple II.

User interface consistency and third-party developers

Remember, Lisa was only dealing with seven applications — that was all you got on the Lisa. The Macintosh was designed (like the Apple II) as something where you had many many applications from third-party developers. And so we took the Lisa user interface, grafted it onto the guidelines that had come out of the Apple II Style Guide and Apple II Guidelines efforts, and published that for third-party software developers to use as style guides for their own applications.

[1:28:05] I remember very very very clearly that one of the massive controversies around the development for the Macintosh circa 1982–1983 was [that] developers would come up to us and say, You know, if you make the user interface consistent and if you put all that software in ROM that makes it— you know, if you make it hard to write to the screen directly, so that we have to use your user interface software to talk to the user, how are we ever going to make our applications unique and stand out and be different from each other in the marketplace?

They found a way. I’m very happy; but the human interface and the idea of a consistent human interface — much less a graphic one — was very very controversial among software developers, and only by having the user testing under our belt to show them that hey, this is going to add significant value to your product by making your product easier to learn and easier to use, especially for people who already know another application, were we able to really convince them that a consistent graphic user interface was a good thing to have.

[This is at the core of what represents, and has represented for years, a ‘Mac-like application’ or a ‘Mac-like feel’ or a ‘Mac-like experience’. And it’s something that, regrettably, has increasingly been fading away after Steve Jobs’s passing. It’s true that nowadays users are generally more tech-savvy than in the early 1980s, but I don’t think that’s a good reason to demote consistency in user interfaces, system software, third-party applications, in favour of an “anything goes, just make it cool” attitude. If you stop enforcing your own Human Interface Guidelines, if you yourself constantly break your own guidelines, developers will feel free to do the same and will get lazier overall. The current Mac App Store is full of such examples.]

More user testing, and conclusion

[1:29:42] I want to fast-forward a little, skip through the early years of the Macintosh, and go to a tape I dug up from the Apple library of some user interface testing that shows how amusing user interface testing can be in the kinds of situations and far-flung places that members of our glorious Human Interface Group went to find the truth about what real users would do.

This is a tape of a couple of our user interface designers — Laurie Vertelney and one other person [Espinosa doesn’t remember, then later adds: “It might have been Kate Gomoll”] — who travelled to France to parts dealerships for Renault Automobiles, who were developing a new automotive parts catalogue based on HyperCard. And HyperCard being a free-form toolkit for designing new software interfaces, presented an entire raft of new problems in human interface design. And then they actually went to France to test auto mechanics in their own environment.

[The tape plays between about 1:31:33 and 1:35:31.]

So that, I think, is an illustration of two things:

1. That bad design knows no bounds;
2. That you never get a user interface right.

And that user testing from the earliest times when you have a totally unsaturated market, people who’ve never seen personal computers before, much less keyboards, mice, screens, things like that — to today, when we assume that anybody who’s ever been in Western society has had to have encountered a personal computer at some point and knows the basics of pointing, clicking, dragging, pressing; what a file is, what a document is, how to print, why to print, what a floppy disk is… I mean, I still find it surprising that we don’t talk about sectors and cylinders on disks anymore, which was one of the main things we had to explain in 1978–1979, because there was some reason you needed to know that — I forget why. But yes, some things never go away, and having to test new designs and test your assumptions of what your audience knows is pretty much eternal.

 

---

 

Q & A

At about 1:37:33 begins the Q & A, but this part is a bit difficult to follow in places due to poor audio. Some of the questions and remarks from the audience are barely audible. What follows are some interesting bits from Larry Tesler and Chris Espinosa’s answers.

 

Question: Larry, I wonder if you could comment on the story that’s often told, that Apple ripped off the Xerox PARC work. I know Jef Raskin has refuted or denied that, but it’s such a popular story… Could you go on record as giving your perspective?

Answer: Yeah, well, I actually showed at the beginning of the talk pictures of the Smalltalk interface to see that, in fact, the early user interface designs were very close to that [interface]: the look of the windows, in particular; and the icons in the desktop. But it evolved over time, and the menu moved to the top of the screen, and so on. If you actually look at either a Xerox Star or a Smalltalk screen, and then look at a Lisa or Mac, I think you’ll see a lot of differences. What was taken were the concepts. The concepts that there ought to be overlapping windows, that there ought to be direct manipulation, and so on. But the Xerox Star, for example, didn’t have the concept of dragging things, and it had a two-button mouse (you’d click one place and then click another place) [Tesler makes a gesture as if to imply that you used one button to click in one place, and the second button to click in another place]. It didn’t have a menu bar; in fact there was only one menu that was added late in the development.

But some things were similar: there was a horizontal and a vertical scroll bar. So certainly the concepts came largely from there, but as you see some of the concepts came from other things — from HP systems, UCSD, from Apple II, from some work that was done at IBM that was published around the late 1970s… So there were a lot of origins for it. I think the Xerox work had a lot to do with it, but usually if you sat down to try to use a Star or Smalltalk you would find that there were, I think, more differences than similarities in what you would actually see and do.

[1:40:32] [In reply to the question: The user testing that was shown for the Lisa had to do with novice users — did you test for how people acculturated over time? (I’m paraphrasing), there is this interesting bit from Chris Espinosa:]

One of the constant tensions — and this was true on the Macintosh as well, especially because we had the benefit of the Lisa work before us and some of the Lisa machines — the constant tension is that the people who are designing are almost always by definition ‘expert users’, and will often overlook that what they think is obvious, is not at all obvious to a novice user; and so there’s constantly the dilemma (which you’ve seen historically in Mac system software) that the expert users want to put in the features they want to use, but the people who want to keep this system pure for the novices want to resist those.

And if you’re lucky, you get a system that is easy to approach for the novice, and gradually unfolds itself for the expert. And if you’re unlucky, you get a lukewarm mediocrity between the two, where it’s a little too complex for the beginning user to understand, but still not nearly powerful enough for the expert user. And some of our designs and some of the industry’s designs have been gradually unfolding, and others have been just plain mediocre.

[I think this is a perfect snapshot of the current situation with iOS.]

[1:48:41] Question: [inaudible]

Answer: (Larry Tesler) …Yeah, like the Xerox Star and the Lisa. The idea in both groups was that people would only use a few applications. It’s kind of true: most people only do use a few applications, but the conclusion that therefore it wasn’t necessary to have third-party applications was kind of ridiculous.

Actually in the Lisa it turned out we did have a place for third-party applications. We thought for certain vertical markets there would be third-party applications and we’d have accounting software and so on. But even then, we were thinking very small-scale, like there would be one page layout application, and there would be one accounting application, and, you know, a couple of vertical market things. If we ever had 20 or 30 applications, that would have been a very large number. Very different from the Mac, which in the very beginning was gonna try to do the same thing as the Apple II and what the IBM PC did, which was [to] go for lots of third-party applications.

I think one of the reasons the Lisa was designed as it was, was to try to justify why there was this project going in the company. We already had an Apple II and an Apple III — why do we need this other thing? And well, the Apple II and the Apple III are going to have all this third-party software, but the Lisa won’t. It was kind of a differentiator, it was kind of a closed system that was supposedly [meant to be] a plus — and it turned out to be a major minus, of course.

(Chris Espinosa) Well, that was not necessarily unique to Apple at that point. Remember, one of the leading software companies of 1979–1980 was Personal Software, which became VisiCorp, and their flagship product line at that point was a failed product line called Visi On, which was an attempt to expand VisiCalc into a comprehensive suite of interacting applications: a word processor, a database…

WordStar at that point was also trying to expand, and everybody was trying to do what Microsoft has successfully done with Microsoft Office. Which is, turn the thin end of the wedge of getting one successful application (which Microsoft had with Excel on the Macintosh) and turn that into a major suite that delivers all of the application computing needs of a given set of users. Microsoft has done it successfully, and one could argue that the default computing platform right now is Windows with Microsoft Office and not very much else.

So, I don’t think that was necessarily a bad idea; [The Lisa as a closed system focused on a set of office-oriented applications] it may have been many years ahead of its time, but Microsoft was selling Microsoft Office for Macintosh in 1985. I still have the box on my shelf where they supplied the word processor, the spreadsheet, the filing program, and the terminal program in one box for one price for the Macintosh. So, office suites certainly were not a dumb idea of 1981 — that’s something that has really monopolised the industry.

(Larry Tesler) That part’s true. The Lisa was really one of the first suites in addition to the ones that Personal Software did. And it was also probably the first multitasking personal computer. Basically ahead of its time… and missing the main point, which was: you needed a low-cost platform that had reasonable performance and that had lots of third-party applications.

[1:54:45] [Here is another interesting bit by Chris Espinosa:]

…I don’t think acculturation had no effect [on human interface design]. I think what acculturation has done [is that] it’s made us soft. We don’t address complexity anymore the way [we used to do] — we sweated over complexity in 1981; we were deathly afraid of complexity. We take it for granted now. You look at Fry’s [Electronics store] and it’s scary the kind of things we get away with.

(Larry Tesler) I think it has made some things hard to change. When Microsoft announced they were gonna go to single clicks instead of double clicks on the desktop, some journalist said, See? They’re leaving Apple in the dust. You’re still on two clicks and they’re moving to one. I said, Our users have been doing this for 12 years — there’s no way they’re gonna change. We’re never going to change it. Maybe Microsoft users who’ve only been doing this for a couple of years can change. But, as it turned out, even a couple of years using Windows 95 was too much, and Microsoft had to back off on making users use single clicks, because even two years was too much: people won’t change.

 

---

Finis

---

 

“Origins of the Apple human interface” lecture — an annotated transcription was first published by Riccardo Mori on Morrick.me on 13 April 2019.