 |
Introduction
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
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
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.
Applications
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.
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.
Demonstration
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
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.
 |  |
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.
 | |
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.
 | |
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
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.
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.
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)
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.
Conclusions
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)
|  |
Home 
was
a panel called “Honoring our elders II,” dedicated to Xerox Star and Apple Lisa. It took place on April 22nd, 1998.
