GUIdebook: Graphical User Interface galleryHome > Videos > Apple Lisa at CHI 98
Go backDemonstrationsApple Lisa at CHI 98

One of the sessions of the CHI 98 conference Link points to external site was a panel called “Honoring our elders II,” dedicated to Xerox Star and Apple Lisa. It took place on April 22nd, 1998.

Below there is a transcript of the second part of the panel, with Frank Ludolph and Rod Perkins presenting the Apple Lisa computer. The paper titled The Lisa user interface supplemented the demonstration.

The video was made available courtesy Frank Ludolph and transcribed by Marcin Wichary, with thanks to Nathan Lineback.

The demo part of the session is available for viewing.

Size: 373 MB. Length: 23:39. Format: AVI XViD (download for a PC Link points to external site or for a Mac Link points to external site). Resolution: 640×480.
Play this video

The whole session in lesser quality is also present at DigiBarn. Link points to external site



This image can be zoomed
Ben Bederson (session chair): So, we have Frank Ludolph and Rod Perkins here now, who were both on the Lisa design team. They both have literally decades of user interface experience. Frank Ludolph had worked on Taligent and is now at Sun. Rod Perkins was at Apple and ATG [Apple’s Advanced Technology Group – MW], worked at Spider and 3DO and is now at Interval. And everything is working, it looks like it is. We’re ready to see Lisa.

Rod Perkins: Thank you. So, I’m gonna talk to you about the Apple Lisa. This is a project that was started in 1978 at Apple, and the product itself didn’t come out ’til 1983, so it had a long period of time to sort of iterate over the design and come up with new ways of doing things. Most of you have probably heard of a Lisa, you’ve definitely heard of a Macintosh, but Lisa, as you can see, predates the introduction of the Mac by a couple of years. Frank and I were part of the software team. Frank worked mostly on the system software side, and I worked on the applications side, so you sort of get both chance during the question and answer period to ask questions on both.

But we’re gonna use this session to really talk about the design goals behind the machine itself, and give you a description of the system; the hardware and the software, what actually went into the box. And Frank will then talk about the user model – how people were expected to interact with the machine. And since this is a demo session, we’ll spend most of our time actually just doing the demo and giving you all the ins and outs of what you did to do something with the box itself. And of course at the end we’ll have a question and answer period.

Now, if you’re interested in more of the design process that we went through, there is an article that Frank and myself and a colleague, Dan Keller wrote for Interactions magazine for January ’96, and I just refer you to that if you’d like to get more sense of what process we used in order to create the machine itself and iterate on the design.

Frank Ludolph: ’97.

Rod Perkins: ’97, thank you.

Design goals and target users

Design goals
This image can be zoomed
Rod Perkins: So, let’s just start with the design goals. Our target customer was very much the same as the Star, this was: office professionals. And we defined office professionals as the secretaries and managers – and even the executives to an extent – who had a number of tasks performed every day, but they had to perform those tasks in a highly interruptive environment. That meant they’d start something, they had to stop prematurely, go do something else, come back to what they needed to finish, and then that’s how they ran their day.

Most of these people had really not much computer use. In fact, we looked at the office tools that they used in 1978; most of these things were done on typewriters, whereas Dave mentioned [this refers to the Xerox Star demonstration, hosted by David Curbow and David C. Smith earlier during the same session – MW] 3070 block-mode terminals if people were fortunate to be hooked to a computer system. So they really didn’t have a very rich form of interacting with their machines. What we found during that period is that PCs were still very much used by hobbyists, and the interfaces to them were very suited towards hobbyist. Before we’re gonna do something that was going to be used for office professionals, we need to do something different. And if you need a little perspective, VisiCalc – which is the spreadsheet application that really broke through for personal computers – really hadn’t been even invented yet when we started to think about what the Lisa should be. So, we thought our competition was really gonna come from the dedicated word processing machines. In fact I can remember going to the National Computer Convention in ’79 and really looking at the linear word processor, because this was one of the things we thought we would have to compete against.

But to a certain extent we used this whole definition of the user to define what kind of capabilities that we needed to design into our user interface and things we needed to pay attention to. So we used that targeted audience to create the qualities of the system. So one of the first things was that we wanted it to be quick to learn and easy to use, and we set a design goal which basically said “we want to introduce someone to the machine and within 30 minutes have them creating documents and being able to print them.” And again, these are those people who have never used a computer before, who perhaps have some allergic reaction to keyboards, now whatever it might be. Now this was the design goal. And it really drove a lot of the design, so that if we had a decision to make, we always made it on the part of making the machine easier to use.

Now, we also had similar goals for the hardware, in that we wanted to make it user-serviceable. This was again something going to go into a corporation, and they needed to have confidence that this machine was going to be something they could maintain. So, the machine itself could be disassembled and reassembled in a short amount of time and when you plugged it all back together again you didn’t get the blue screen of death, you hopefully got a nice pleasant tone and off you went. So, the user interface design even went down to what the hardware looked like and how it performed.

The user interface philosophy

Rod Perkins: Now, the user interface itself was designed to be explorable. That meant it was very visual – we had menus, we had windows, everything was modeless, nothing was very hidden from the users. If they wanted to find something, you could just explore through the interface and discover where it might be. We adopted a philosophy of more “see and click” as opposed to “remember and type.”

We also wanted to make sure that the things that the people did within their applications, things that they learned, that something could be applied later on in time when they learned something else about the system. So there wasn’t “learn this part of the system, then learn something completely different in another part of the system.” So this whole notion of gradual learning or leverage learning.

And again, since this was going to be going towards people in an office, who had never really used a computer before, we thought “well, the system had to be very robust; we can’t ever lose data, and it has to be something that people develop confidence in.” So, a lot of the system design that I’ll talk about later went into making sure that the system really maintained itself over time.

Support for quick context switching: again, person we were designing for needed to be able to switch from task to task very quickly and very easily. But one of the other things that drove us, and especially the user interface side, was that we wanted to make it fun to use. It shouldn’t be something that people felt they had to use because it was part of their job, or that this was going to be a real problem for them to learn. That it should be fun, and the interface should be fun for them to interact with.

Hardware and operating system

System description
This image can be zoomed
Rod Perkins: So, if we move on to the system description, this was using a Motorola 68000 – not a very powerful machine, but state of the art at the time. Five megahertz. We had one megabyte of memory, we actually used 64K parts, and ours, I believe, is filled with 16. And in some of the later machines we actually had 10-megabyte hard disk, but the first machine was actually floppy-based. The display was 720 by 364, so it gives you a fairly high resolution display for that time.

And the input device was a single button mouse. And this is an example of where we really didn’t know what the best solution would be, and we had lots of discussion about that. The mouse on the Lisa actually was 3-button mouse, but we had only shipped a single-button version of it, and we would then experiment later if we needed to change that decision.

But thinking about just that, hardware, that’s one percent of today’s processing power. Some of you actually have a Pilot or Palm PC in your pocket right now – that machine is more powerful than the Apple Lisa that we’re going to be running our software on today.

So, the software that was in the machine really tried to address some of the major issues about how the machine would be robust and how we’d operate in this highly interruptive environment. So, first of all it was virtual memory underneath. We had a preemptive multitasking operating system, so it was very easy for things to switch back and forth. We also had a redundant file system underneath, which meant that the file system itself could take simple hits from either bad floppy disk or bad disk blocks, and still be robust enough to get the person’s data back.


Rod Perkins: And then on top of all this we shipped a number of applications. The Lisa had a suite of seven applications, which you can think of like the Microsoft Office of today – there’s a similar kind of applications that you would find there.

User model
This image can be zoomed
But the main thing Apple wanted to try and do was create a credible business machine, based on its perspective as a PC manufacturer. So we were coming at it from the Apple II perspective, in that you needed to have an open software environment. People needed to be able to develop for this machine. Likewise, we wanted to be able to support whatever applications people could come up with for the box because, again, we were still experimenting with the Lisa and wanted to make sure that we left it open for future refinements. So Lisa itself ran Lisa software, it also ran Macintosh software – if you hadn’t seen Lisa before, you might’ve heard it by different name, called the Macintosh XL – but it also ran UNIX, it ran different languages, such as Smalltalk, and hosted a development environment as well.

The user interface essentials

Rod Perkins: So, the Lisa user interface tried to present a style of interaction that was very close to our target user. And this was the desktop metaphor. And in developing that interface there was a number of things we learned, but actually were not transferred when the Macintosh was created. And most of these things revolved around what the actual user model was, and how the user would interact with the machine. And that’s what Frank will describe.

Frank Ludolph: Okay. As with the Star, and probably evolving from Smalltalk, the idea was to use an object-oriented desktop, which meant that we worked with documents and tools, we didn’t talk about applications and disk files and processes, because those weren’t relative to what the user was used to in his environment. It was a desktop metaphor, but we did recognize that we’re still a computer, and in a few places we in fact made that quite clear – things like disks, because they weren’t file cabinets, they were disks. And you had to do certain things with them that you didn’t do with file cabinets. The interaction style was WYSIWYG direct manipulation and, importantly, rather different from the Star, it was “select and use a menu.”

So now we’ll drop into the demo and we’ll go through these topics in about 20 minutes.


Demo time
This image can be zoomed
Frank Ludolph: Notice the transitional animation, people had been afraid of things jumping out at them since day one and so we tried to soften that – we didn’t want windows just popping up in the middle from nowhere, kind of disconnected from the user action. Here I’ve opened up four different documents. We had different document types. Basically, the background for this group was of course an Apple II, separate applications. Each application had a different object type, or a different document type.

So in this case I’ve opened up a calc – a spreadsheet, a graph, a project – which was a timeline type of thing – and a draw, a drawing program. One of the things that differentiated Lisa from the Star was that it was what I would call “true direct manipulation.” You just grabbed the object and moved it, you didn’t do first select, then hit a Move key and then point somewhere, or perhaps drag it, depending on what the case was. And, of course, we obviously had overlapping windows, which the early Star didn’t, and one of the reasons for doing that was because we had such a small screen. We didn’t have a two-page display.

Window and document operations

Four documents
This image can be zoomed
Frank Ludolph: One of the things that we felt was very important in this was that we have to use a phrase “pixel-perfect graphics.” Most systems – in fact, as far as I know, all systems, but I may be incorrect – at that time, when you moved the window it left a hole. It didn’t refresh the background. You actually had a menu command entry “refresh the desktop,” or the other windows that were corrupted when you moved something. In this case I’m gonna move this over to the side. Notice there are three windows behind it. And what’s going to happen, I’m gonna describe it to you because that happens so fast you’ll have to look.

The window frames will be immediately redrawn and then they will fill in – I hope – from front to back. They were supposed to. You see the content filling in sequentially front to back. And that time they tended to use Painter algorithm, which meant it was like lying down paint. When you had overlapping objects, they would first draw the thing in back, then draw the next thing over it, then the next thing over that, and what you saw was a lot of visual noise, a lot of visual flashing. So the intention here was to eliminate that and create as stable a visual image as possible, and for that Bill Atkinson developed an update region concept, and this was an application of it.

In fact it was so complete that Bill came into my office one day and said “let me show you what I’ve done,” he’s turned on the machine, he said “okay, now draw a figure eight using the mouse.” And you know what that looks like, right, on the screen, nice and uneven all the way around. He said “okay” and he pushed the button, and text started smoothly scrolling through it, clipped perfectly at the edges, as it went up. And set a standard for graphics that in fact I don’t think we’ve fully accomplished industry-wide yet. It’s just something we should be doing all the time.

One of the other things that we did here, this is multitasking operating system. And in later release – this is actually the third release that you’re seeing, which is not very different in terms of the user interface – as a window was deactivated, it was given a chance to save a PICT, a graphic of what was in its window. And if it did that, then the desktop manager would use that in refreshing windows; and that meant that we didn’t have to swap in a lot of applications and do disk swapping in order to just repaint the windows in back. It did a lot to improve the overall feel. The set up was such that you could start using the front window immediately, even when it had to swap in the other applications, but it was slow and sluggish and very distracting.

Desk menu
This image can be zoomed
One of the capabilities – remember, we got 1% of the processing power here, folks – the model in handling documents was that if you were working on them you could either set them aside or put them away. In this case I’m gonna set this aside and you’ll see it’ll kind of animate back and it’s now actually an icon on the desktop. In order to be able to get a hold of that, we can actually pull down the Desk menu on the left and the Desk menu on the left had a list of every icon that was on the desktop. So this is a way of getting at things that were obscured. The ones that are checked, you’ll notice, are the windows that are actually open. So if I just click on or select Calc then this window comes back.

One of the other things I want to mention is that when you activated a window, only one window at the time came forward. Again, this was document-centric, not application-centric. In systems today, you’ll often find that when you click on, say, one Word window, all the Word windows will come forward; or one drawing windows, all the drawing windows will come forward. That’s application orientation. What we did is we wanted to make it simple to work on a graphic and a text document relatively side by side, or at least overlapped, and to be able to move back and forth through those with a minimum of distraction, even if you had other windows. So just clicking on one window brought that document forward. To simplify context switching there was a way of setting everything aside. Notice again the transitional animations.

File/Print menu
This image can be zoomed
Again, keeping with the document orientation rather than the application orientation, notice that there is no Quit. There is a Set Aside and a Save & Put Away, which are equivalent of Close operations, but there is no Quit. The desktop manager managed all the processes, so the user never started an application, they never quit an application, and the desktop manager would keep one version of a process running, even if it didn’t have any windows open. Most of the applications handled multiple windows at one time. But even if they were no windows open, it would keep a process running, so when you went to open another document of that type the process was already initialized, and all it had to do was open a document. The difference went from about 45 seconds doing an initial start up an application – that is, start up the process, initialize, and open a document – down to around generally 10 to 15 seconds, which is still long, it’s much too long, even today it’s too long, but it was a terrific improvement in terms of the usability of the system, and user’s perception.

This image can be zoomed
As an aside, one of the things I’d like to show you is that we used something called “placeholders.” Most of you are familiar that when you open something from the desktop it leaves some sort of graphic behind to indicate where it was. But the systems generally today don’t leave anything inside of a folder to tell you where did that belong. So, for example, if I take this and drag it out, notice there’s still a place left for it. What this meant was that you could actually arrange things spatially – group them, if you would – in a way that you liked them, move them to the desktop because you were working on them, and when you put them away, they actually went back to the same location, rather than going to the first available location. It’s a small thing, but it actually made spatial layouts useful. You can do that today, but it takes more work.

Again, keeping with the document-centric nature of the interface, there was no New command in the application, or in the menus either. In fact, there was no way to start an application without opening a document. To create a new document, there was stationery, various kinds, and you would use the same double click action that you use to open it, to create a new document. So, Dave, this is the answer to your question. We created stationery which you could not modify, and when you went to create a new document, you just tore off a new version and you could open that up and use it.

To give you an example here, I’m gonna open a blank paper and we’ll create a new piece of stationery. Many of us don’t need to use too many forms, at least that we create in our daily life, given the nature of the work that we do – I don’t know, I’m assuming that – but there are a lot of people that do. So I’m gonna take is – assume this is a form that I’ve created, a template for something – and now I just point at it and say “Make stationery.” Please... And when this comes away, you’ll notice the icon has changed slightly. Now it looks like a little stack of documents, and that was the indication of the stationery. And if you wanted to change it, you just created new document, made the changes, and saved that as stationery.

Trash can

This image can be zoomed
Frank Ludolph: I’m gonna take this, ‘cause I don’t really want it, and I’m gonna throw it in the trash can – we called it Wastebasket, actually. And what we did, the reason for the Wastebasket was to eliminate the problem of double delete. “Delete this.” “Are you sure you wanna delete this?” comes up the dialog, and you press the button and say “Yes, I do.” It becomes a very automatic action and what happens with a lot of dialogs that meant to protect you is that the default action is in fact the unsafe action. And the result is, well, let me describe something that somebody mentioned to me – I won’t mention the name – today in a session. They wanted to empty the Wastebasket, so they went to click on the Wastebasket, and say “Empty trash.” But they accidentally selected a disk. And the dialog came up and the dialog said “Do you want to initialize this?” And even as their hand reached for the Return key, the person said “Oh, this is a disk, I don’t want to do this.” But the hand had a life of its own. (laughter) Bang! And they lost their disk.

How to get things out of the Wastebasket? What happens was: when you threw something into the trash, it removed from the trash what was already there. So it was kind of like a one-level undo. So there was no need to go up and say “Empty trash” at some later time. If you look at the Macintosh system of today, they’ve actually created a triple delete. So you put something in the trash, and it stays there until you say “Empty trash,” and then when you say “Empty trash” it puts up a dialog and says “Are you sure?” They do make it very difficult to remove things. A thing we’ve tried recently in a new system is a timed delete, so things will stay in there for a period of time – maybe two days, but generally user-settable – and the garbage collector just comes around, the janitor, comes around every couple of days and empties the trash. We didn’t have a chance to do that, we didn’t think of it, otherwise we might’ve done it.

Document saving

Frank Ludolph: I’d like to talk now a little bit about the save model. In a Star, every change you made was permanent. The document was always saved. It was a little bit like Hypercard, if you’re familiar with that system that came along a little later. And, as Dave said, unfortunately there was no undo, so you couldn’t undo the last thing. We did have undo, but we put in the menu, so if we didn’t implement it, we could’ve taken it out. (laughter) Anyway. So, here’s a document and if we scroll around you would say “look, it’s kind of a floor plan for a kitchen.” Not too relevant. Again, this is noticeably different from the Star, when you sort of had letterset type paste-its that you could copy and paste it in. Here you picked up a tool and drew it, which is pretty similar to what most of you are familiar with today.

So I’ve made a change, and my boss walks in and says “Here, I want you to work on this” and he hands me a diskette. Now, you say “well, but nobody does that anymore,” but we do have larger removable media now. Things like Zip drives and other things. So I’m gonna go, and I need to free up my diskette drive, so I go to select a diskette and I eject it. Now on a Macintosh today, it would say “I’m sorry, you can’t do that, something is in use”; in parentheses “You guess what it is” (laughter) Oh, dear. I’ll explain this in a moment. On a Windows system, it ejects the diskette. What we were going to see, and it didn’t happen, was that actually the document would be automatically suspended and the diskette ejected.

Technical difficulties with the diskette
This image can be zoomed
Let me try this once again. I have a feeling it’s not going to work, though; my disk is probably corrupted. Okay, I guess I have to tell you. Sorry, this worked all day, so if you came this morning... (laughter) you saw this happen. What happens is that the diskette comes out, the window goes away, and the diskette comes out, into your hand. And what happened is, that nothing was saved, but all the edits are persistent. Here I’m waving the diskette around, see it? (laughter) Then, when you’re finished and ready to resume this, either on this machine or on another machine, you would put it back in. What happened is that when the diskette was ejected the document was suspended, and all edits were written out to a suspend file, separate from the regular document. When I put this diskette back in, you would see the diskette reappear, the icon come out onto the desktop and this window would open. And then some of the applications... the spec was that you could actually undo the last change you made. Even after that. This one unfortunately didn’t do this; given what I’ve just seen, I’m not sure the following is going to work either.

Reverting to the previous version
This image can be zoomed
You can see it here a little bit, you could say “Revert to previous version.” I’ll probably be able to do this anyway. And so what you could do is you could remove all the changes you made since you last saved the document. Now the system was designed to be robust. The applications periodically put out this edits file, kind of an autosave, but it didn’t overwrite your existing saved document. When the system was turned off, when a diskette was ejected, the document was suspended. Here I’m going to undo the changes, Revert. (laughter) It’s been a while since I’ve used this, but this really is my system. (applause) And by the way, it was really 10 years ago. The Lisa clock stopped turning over in 1995. (laughter) We don’t have a year 2000 problem. (laughter) So, the idea here was that Save was something you did when you wanted to, because you’ve made a set of changes to a document that brought it up into a new consistent state. That was the only time you ever might have wanted to save, and you never actually had to save if you didn’t want to, but then you couldn’t revert. You did not have to save because you were paranoid, you did not have to save because you removed the diskette, you did not have to save because you turned the system off. That made Revert useful, because the last saved version was a version which you thought was consistent. Essentially we had kept two versions of the document – the current working version and the saved one. And had we had time, we probably would have added a real versioning system that would keep them later.

Transparent file system

Frank Ludolph: Now, where was that suspend file? Well, it turns out that the icons on the desktop are not disk files. The icon on a desktop is an object. And behind it may be zero, one, two, three, n disk files. The user never dealt with disk files directly. What this did was it kept down the number of icons on the desktop. There wasn’t a second icon for the suspend file. There was not a second icon for, perhaps, a lock file, or something of that nature. The LisaList program kept a disk file for each index into this flat file it managed. You only saw one icon and you only dealt with one icon. And when you transfered something to another place, everything worked; you never had a chance of corrupting the object by accidentally removing or losing one of the disk files, because of something you did accidentally.

Data interchange (copy and paste)

This image can be zoomed
Frank Ludolph: I’m gonna tell you about something, very briefly because we don’t have much time. We used separate applications, we expected other applications to be written. So one of the things we wanted to do... Oh, there’s something from earlier editing. We used the Clipboard and we defined several standardized data interchange formats, so for graphics it was a PICT file, there was text, there was tabbed text – which was tabled – and virtually every application could copy its data as one of those forms. You would go on a clipboard and you can paste it into virtually all of the other documents. So while it was dead, in a sense that you couldn’t edit it once you have transferred it, it did give us the ability to integrate virtually any kind of data type – “virtually” is a word it says I’m lying, not every, there were a couple that wouldn’t – virtually every kind of data type from every kind of document, every other kind of document. So, my Gantt chart, I could move from my project management and paste it into my Write document. We didn’t have smart objects, but that was partly because we felt we didn’t have time, and we were a multi-application environment. So, that’s a little bit about cut and paste, and the clipboard, and common data interchange formats.

Command set simplicity and consistency

Frank Ludolph: Lastly, I’d like to talk about another way that we tried to make the system simple. Let’s start off, and we’re just going to duplicate a document, and what we did here is we did have a Duplicate command, we created a blinking icon which represented the duplicate you’re about to make. You could then take and drag it and put it wherever you wanted it to be, rather than immediately duplicating it on the same storage, the same disk. We expected a diskette-based system, there might not have been room, and it also prevented kind of copying it once to the diskette it was on, and then copying it again to some other place, that’s really where you wanted it.

Now what this did, is it kind of gave us kind of an ugly – what’s happening here, that’s a duplicate right there, on the desktop, and it’s on the same storage medium. What this did is it gave us a way of doing a lot of other things. So, for example, if that document was too large for the diskette, it would bring up a dialog and say “It’s too large, would you like us to split it across several diskettes?” and you could say “Yes,” and it would ask for diskettes in turn. You could back up the hard disk in exactly the same way; I’m not gonna show you, ‘cause it takes too long (laughter), as you might expect. But you would just say “Duplicate,” and drop it on a diskette, and would come up with a dialog and say “Do you want to back this up? Do you want to do a full backup or an incremental backup?” And you would start doing the diskette dance again. (laughter) If you wanted to duplicate a diskette, you would point to the diskette and say “Duplicate,” and it would say “Do you wanna copy this to another diskette?” – you might copy it to the hard disk and that’s why it asked the question – and if would said yes it would suck everything off of that disk, eject the disk and ask for a new one, and when you put it in it would write everything out.

So this one Duplicate action – this is in a style of Star in some sense – was used to duplicate something, to make a copy somewhere else, to back up, to duplicate diskettes, and these were all built in, they weren’t separate utilities in the system. These were things that the user did all the time. The user didn’t have to know about running this utility or that utility, they just used the basic duplicating and copy actions.

Move vs. copy for dragging

Frank Ludolph: One thing I do want to say – the Mac takes a lot of heat for this. I’m gonna drag this over to this diskette and drop it, and it’s gonna take a little while to do it. What happens is: Lisa does a move. Now let’s say I’m working on something and I wanted to give Rod a copy of a document. And I just sort of grab the icon and drag it over and drop it on a diskette. I’ll pop out a diskette – that’s why we failed, there’s not enough space left – I would take out the diskette, give it to Rod, and he would go out and guess what – I don’t have the document anymore. (laughter) Because it was a move. Nice and consistent, but it creates an error situation which is really hard to recover from, ‘cause Rod just got on a plane and took off for Florida. (laughter) So while the Mac does an inconsistent mechanism, it works out a lot better, because you don’t have the error condition, so that’s one of the reasons they did it. There were other things they did, and I’ll talk to you afterwards, offline maybe, and we can talk about why they’re good or bad. That’s another issue.


This image can be zoomed
Frank Ludolph: Anyway. To finish up, just to get to some questions here... We all stand on the shoulders of others. And we clearly stood on the shoulders of programs like Sketchpad, and I would say not enough on the shoulders of systems like Augment. Certainly Smalltalk and Star were part of the things that we stood on, and other system stood on our shoulders. The Macintosh copied the interaction model, they copied the desktop metaphor. They did not copy our user model, however. What they did is they exposed the standard, traditional computing model underneath, so that the users also dealt with processes, applications, and disk files. We tried to hide that, Star also did an extremely good job of hiding that.

We hear a lot of people saying that today’s systems are too hard to use, and we’ve been working on this for 20 years, so how come? Well, we need to make sure that we keep them simple. We can do that by having more concise, more direct, simpler user models and sticking to them. We can do that by putting in built-in support for common operations, such as the storage management, and the context switching that I showed you. And lastly, we can clear out some of the UI cruft; we’ve developed a lot of different UI mechanisms over the years, and we don’t really need all of them, although we tend to use most all of them now. So that’s another thing. That’s a pretty major step, though, we take a lot of heat when we change the UI, we take a lot of heat from our users. I’m sure you’ve had the experience.

But, at any rate, I’ll say that if you want to see a system that uses some of these ideas, if you come downstairs to the exhibit area to the Sun booth tomorrow morning, between – I think – 10 and 12:30, I’ll be demoing the system called HotJava Views, which is a user environment for an NC. We used some of these ideas, and with some of these kinds of simplifications. And you can take a look and see how a different user environment might look designed to be quite simple. But anyway, enough of that plug, do you have any questions? Thank you very much. (applause)

Questions and answers

Ben Bederson: There’s a microphone in the aisle here, so, we actually have several minutes for questions.

Audience member: I guess I feel slightly guilty being part of the UI community and, you know, what have we been doing for the last 20 years kind of comes to mind. (laughter) You know, we’ve got color now, but... (laughter) and I guess what I’m wondering is, you didn’t say how big your software team was for the Lisa, what was it? How many people?

Frank Ludolph: I think it was about 30 people, including the operating system and all of the applications. They were generally 2 or 3 people per team.

Audience member: Okay, I worked for a company that Frank worked for also, Taligent, before. And, they had 300 people working on an operating system. And I’m just wondering if the difficulty and the problem and the bloat just comes from too many people working on a project? You know, the Star had – what – six people?

David Smith: I just realized I had completely misstated that. We had three hundred people. We had 6 UI designers. There were 280 programmers, so, four people.

Audience member: So, what do you think might have stalled the progress in this area?

Frank Ludolph: A lot of it has to do with backward compatibility. Our desire not to get the user angry at us in the immediate future because we change something that they’re used to doing. We tried to be responsive to users, but it’s not always necessarily the best thing to do. Sometimes we have to say no. There are some other issues. We had a pretty clean and consistent UI across all of the applications. That’s primarily because the manager of the application group ruled with an iron fist with respect to the UI. This would’ve looked a lot more scattered had Larry Tesler not basically managed the UI in a way that he did. So it takes a very committed manager of the software team also to keep the UI consistent.

Rod Perkins: And I would also add that we had a very good model of who we thought we were designing for. And to that extent it set a number of constraints on what we could do and how we could iterate on the design and come up with different UIs for them. So, there you have a very well-defined interface just based on a well-defined customer.

Frank Ludolph: Dave wants to say one more thing.

David Smith: If you wouldn’t my just adding to the answer here... Actually, there’s nothing about Star and Lisa that couldn’t be done today. But it’s gonna take a whole different discipline. The easiest thing in the world’s when you have a new feature – just make up a new command for the feature. But all that does is make your life easier and the user’s life harder. So you’ve gotta have the discipline to turn that around if you want to achieve this.

Audience member: Hi, I was trying to think... this question, I think, might be relevant to other people and so I feel okay about asking a second question in the same session. And that is... Let me preface it by saying that concern for the user shows through so strongly in both of these project that you look at them and you think “How could someone seeing this not feel almost cared for in a special way?” (inaudible) these things you will not phenomenally successful. Those of us who worked for profit-making or supposedly profit-making organizations are instructed to measure success by the profit we make. And as someone who’s done things in the past that have not made a profit either, it sounds a little like whining, but, you know, what can you tell us about the meaning of success and failure, because there are maybe other people in this room, who either have had similar experiences, or will, sooner or later, in their careers.

Frank Ludolph: First of all, one of the really rough things for both of these products was the cost. To get the first Star workstation in your company cost about 60 thousand dollars. That’s because it took a file server, a laser printer – which were really expensive at that time – plus the workstation. The next workstation cost you 15,000, the incremental cost was smaller, but that first one was pretty hard. Apple Lisa was ten thousand dollars, which was still pretty expensive. When a Mac came out, it finally got down to a price where people could being to think about it. But the original Macintosh, remember, I gave Mac kind of a hard time up here, but you have to remember it had a 128 Kbytes of memory and one diskette. It could not have done what we did. It simply could not. It needed the system support that we had in order to implement this user model. So I think what killed our systems primarily was the expense. It didn’t help for the Lisa that the Mac was rumored to come along six months later, and it’d be just like the Lisa and cost only (inaudible) ten thousand, so that was pretty hard too. I’m afraid I’m not really answering your question, but I’m telling you why I think these products didn’t succeed, which hopefully says other products that do thrive for simplicity do have a chance.

Audience member: Well, I guess behind my question is: Maybe these products are wild successes, but you know, we weren’t using the terms properly, or maybe there’s more than one kind of success.

Frank Ludolph: Well, Fred Brooks in his “Mythical Man-month” said “Be prepared to throw one away.” Those of us that were working on the Lisa didn’t realize we were working on a throwaway. (laughter)

Frank Ludolph: However, the Mac did pick up our interaction style and at least picked up the metaphor, but at each of these stages that you’ve heard about today – Augment, Star and the Lisa – there were things that got dropped in the process of making the product something that could be afforded. And I think it’s worthwhile to occasionally go back and look at the systems. Normally what got carried forward was the visual stuff, what got dropped was the stuff that was hard to see.

Audience member: Thanks.

Audience member: First I wanted to say thanks, they were great presentations, really impressive work that was done, and I feel lucky to have seen the last ever Star demo, ever. (laughter and applause) With that in mind, I have a historical, non-technical question about both. I’m curious where the name Lisa and Star came from.

David Curbow: Star was just the last internal name that we had before we started to ship the product. (laughter)

Rod Perkins: And the Lisa was actually an internal name as well that we all liked so much by the time the product shipped we used it. We came up with the acronym for what Lisa meant, and that was Locally Integrated Software Architecture, (laughter) which was a mouthful to say “it really meant nothing,” but that’s really where the name came from.

Audience member: Was Lisa the name of Larry Tesler’s daughter?

Rod Perkins: It was not the name of Larry Tesler’s daughter, no, and I will deny other rumors about whose daughter it was (laughter), or whose girlfriend it was, or whatever, but... (inaudible) were actually true.

Frank Ludolph: But I got there too late to know.

Ben Bederson: Last question?

Audience member: My question goes both to Lisa and Star. I was wondering if you, in your design, considered tiling windows?

Rod Perkins: I’m sorry?

Audience member: Tiled windows manager.

Rod Perkins: Tiled?

Audience member: Yes, versus overlapped, which was a great, great issue 10 years or 15 years ago.

David Smith: Well, tiled windows really require a large display screen, it’s completely infeasible on a smaller screen. So that’s first off. In fact, if you remember back to Windows 1.0, it was a tiled-windows system on a PC screen, and it was a total flop. The reason we went to a tiled windows scheme was in our studies of people like using the Alto computer, which had overlapping windows, we noticed that a lot of them spent a lot of time and effort getting the window overlapping just right. And anybody who looks at a window system today will see the same thing. So we said, well, let’s just divide up the screen for the user. And it actually didn’t work all that badly, if I had to do over, I don’t know if I would do tiled again, but... it was an idea that was motivated by the users’ concern and I don’t know there was a total success.

Rod Perkins: To an extent we wanted to deal with a person who had to move back and forth between tasks very quickly, and having to look at our screen and the size that it was meant that we really wanted to have as much use of that screen real estate and high resolution graphics as possible. So we really wanted to make use of the full screen and let the people then organize the screen the way the wanted, and using overlapping windows plus the clipping scheme that Frank described, allowed us to very easily get the front window displayed quickly, and then the back windows would fill up as necessary.

Frank Ludolph: Just to put in another plug, if you come down to see the demo tomorrow in the Sun booth, our views was a full screen, it wasn’t tiled, it was a full-screen application again because it’s a small screen. We took a lot of heat for that. Users, at this point, whether it’s in their best interest or not, that’s what they want. So that’s what we’ll give them.

Ben Bederson: I think we all have been very lucky to get to share this afternoon with you all, so thank you very much, we all appreciate it. (applause)

Page added on 5th May 2005.

Copyright © 2002-2006 Marcin Wichary, unless stated otherwise.