For a great discussion of the history of the Lisa's desktop by one of its developers see the following article:
http://www.guidebookgallery.org/articles/thepastpresentandfutureofthemacintoshdesktop
This site also has a large number of rather rare Lisa articles, many from people at Apple who worked on the Lisa:
Here's a copy of this article for this list:
This interview was originally published in Issue 26 of Signal, a publication for Lisa and Macintosh users and developers, in March 1986. Reprinted with permission.
To a first-time user, perhaps the most striking thing about the Macintosh is its use of the desktop metaphor: the folders and other icons intended to help make the Macintosh a user-friendly machine. For a perspective on where those ideas came from, how they were further developed by Apple, and what they might lead to in the future, we interviewed Dan Smith, an Apple Principal Software Engineer.
Signal: Give us a brief history of your career at Apple.
Smith: I’ve been at Apple for a little over five years now. I initially signed on to the Lisa project to work on what we called the Desktop Manager, essentially the equivalent of the Finder on the Macintosh. I worked on that for about two years, until the whole Lisa project was near completion. Then I became User Interface Coordinator for the Lisa project, then switched to a consulting role for the Macintosh, since Mac picked up about halfway into the Lisa development stage. I took some time off from the Macintosh and Lisa to start working on some future projects, did that for about nine months, then got pressed back into service to do a program development environment for the Macintosh, which is what I’m working on right now.
Signal: Were you the desktop programmer? What was the organization responsible for the desktop and the other Lisa software?
Smith: The effort was split up into a couple of different groups. There was the desktop group. Two of us actually did the implementation. I programmed the user interface portion, and Frank Ludolph did a fair amount of the lower level implementation. Then there was the applications group, and that was split up into essentially the different applications that came out: LisaDraw, LisaWrite, and so on. There was also an operating system group, which did the much lower level software.
Signal: How did the ideas for the desktop originate, and how were they incorporated into your design?
Smith: That’s a pretty interesting story. When I started at Apple, the idea of the desktop hadn’t really quite been born. In fact, it was thought we’d do something fairly simple, and it would be a one-person job for a couple of months and it would be over. It was a little later in the project that we realized the desktop was going to be a central part of the entire system. The idea of an iconic form didn’t come along until quite late into the development of the product. We started off with something that was pretty Smalltalk-like. There was a notion of a thing called a browser, which is essentially a table you could flip through, listing the documents you had in a hierarchical fashion. But the whole initial desktop was essentially technically oriented. We went through iteration after iteration. I remember doing prototype after prototype, and trying them on several groups of people, getting it to be more and more useable. But a number of us were not happy with what we were getting, so fairly far into the project a couple of us took a radical departure. We took a fair amount of our own time developing an iconic model, then sprung it on the whole group. It met with some resistance, but the majority of people really liked it. Then it was a mad rush to incorporate it into the final product.
Signal: Exactly who did what? Was the design fluctuating with the whims of a few individuals?
Smith: The desktop had a pretty fiery history. We did have design reviews of all of the components of the system. We had teams: writers and marketing and engineering people who were all involved actively in the product. When we were actually doing the design and programming the application, the specification circulated amongst the teams. They all had a voice in the initial design of the product. As we circulated some of the actual design, and showed some of the prototypes, there was some frustration by some people that the desktop was not as easily useable as we would like. A couple of people, myself and Bill Atkinson primarily, and later Bruce Daniels, snuck off and worked on a prototype iconic model.
Signal: Where did your ideas for the iconic desktop come from?
Signal: How would automatic searching have been accomplished?
Signal: What other desktop capabilities never made it into your final model?
Signal: Were there any schemes that would allow repeatable commands?
Smith: There were a couple. One that comes to mind that was actually done with limited success was to simply record all the actions of the user on a real low level: the user moved the mouse from here to here, clicked the button, typed keys at this point. That allowed us to do little demos where the machine appeared to be running under automatic control. The problem with that approach is it requires you be in the exact same state every time you run this little script, even down to the exact position that icons are on the screen or within their folders. That situation turns out to be very rare, so that approach is flawed. It’s also not something you can easily parameterize. You pretty much specify an absolute action.
Signal: Programmers were disappointed to find that this beautiful, iconic, straightforward, user-friendly, state-of-the-art desktop was built with a fairly old programming language and tools. The Macintosh didn’t come with any new, powerful systems to make programming a Mac as easy as using one. Is there a lack of tools for developers to easily implement new Macintosh programs?
Smith: There’s no question that implementing a Macintosh type of user interface is difficult, and the initial implementation on the Lisa and the Macintosh was done in pretty traditional form. What we’ve tried to move towards is more of an object-oriented implementation that involves extensions to existing languages. In the long run, that’s really going to be the way to develop software for this type of a system. The problem you typically have with object-oriented software is performance and size. Since it’s a general system, you tend to get a lot more software than you actually want because everything is built in, and you may be only using a subset. The size of any application tends to be quite a bit bigger, and the performance often can be quite a bit sluggish.
Signal: Has object-oriented programming really been proven? Both the Lisa and Macintosh have demonstrated excellent user software, but only using traditional, non-object-oriented programming. Apple’s object- oriented systems always seem to arrive a day late and a dollar short and have never really been used to implement anything of commercial significance.
Smith: That’s certainly been true up to this point. Whether you can use that approach or not depends on how much horsepower you have behind you. Smalltalk is heavily object-oriented. Depending on what kind of machine you’re running on, Smalltalk is a wonderful system to use, or it’s just horribly slow and painful. So it’s a combination of the hardware you have, and the software implementation. Programmers who use an object-oriented system are really pleased with it, because of the amount of work that’s already done for them. Developers will gravitate towards that type of a programming solution once it’s implemented in the most efficient possible way, and there’s sufficient hardware behind it to make the performance acceptable.
Signal: Why were the tools that Apple used to implement its first desktop applications never released to developers?
Smith: Great question. The reason is we didn’t have the object- oriented extensions made to any of our languages at the time we were developing the product.
Signal: If the Apple programmers didn’t need finished object-oriented extensions to complete their applications, why did you think third party developers would have to wait for the extensions to be completed before they could get tools for their products?
Smith: The primary reason was because of the difficulty we all faced while developing the applications. We were all working at Apple on a daily basis, and had access to everyone on the project on a face to face basis, and we were still having difficulties in the amount of time it took to implement just a standard user interface. Each of the applications had to implement scrolling, and the menus, and all of the appropriate things, according to the standard user interface and specification. It turned out to be just incredibly difficult to do, and incredibly time consuming.
Signal: Couldn’t Apple programmers borrow each others code and algorithms?
Smith: Well, we tried to some degree, but there would be these slight little differences. It was very difficult at times to trade some of that stuff, because of the way an application was structured. We were essentially pioneering all of those techniques, even the basic design of an application being event driven, as opposed to reading in a little command line and a carriage return and spitting out the answer. It was all quite a bit different from the programming experience of most people there. We just realized way too much effort went into developing desktop applications, and something better had to be done for outside developers.
Signal: How did you get involved with the Macintosh group?
Smith: Towards the end of the Lisa project, Macintosh development was getting much more established. I spent a little bit of time with Bruce Horn and Steve Capps, the people who worked on the Finder, because they were doing the same thing I’d done on the Lisa. We were able to share some ideas. That was useful for all of us. I had already conquered a number of the problems they were facing and, in their development, they had found a couple of interesting solutions to problems I had not found a solution for.
Signal: What’s an example of something they found a solution for?
Smith: They had a user interface solution for the problem of how to get a tool to operate on documents not of its kind. The solution was to simply select all the documents and the application involved, and click on one of those as a set.
Signal: Wasn’t the Macintosh group reinventing the wheel by not letting you write the Finder?
Smith: It was to some degree, but the Macintosh group was faced with constraints which were pretty extreme compared to those on the Lisa. The amount of memory available and not having any real hardware memory management made some things quite a bit more difficult on the Macintosh.
Signal: Was the Macintosh a step backwards from the Lisa? Was the machine sorely underpowered for what it was trying to do?
Smith: Not with respect to the original design goal. The original goal had envisioned the Macintosh as being a personal computer that would run a single application at a time. It would have superior graphics and the Lisa-style user interface. But it was going to be restricted in terms of exactly how much it could do. It turns out that in terms of computational power, in terms of raw speed, the Macintosh actually exceeded the Lisa to some degree.
Signal: Do you feel the Macintosh group did a good job of capitalizing on what the Lisa group had pioneered? Or were not all the lessons learned?
Smith: Yes and yes. They did a tremendous job of leveraging off what Lisa did. All the graphics routines carried over, almost to the byte, thanks to Bill Atkinson’s foresight. The window and menu management routines were essentially brought over as is, at least as far as the interface. The major changes that had to be done for the Macintosh were that things had to be recoded in asssembly language in order to get the program sizes down. But most of the interfaces and stuff like that were pretty much the same, but with improvements along the way. In that sense, the Macintosh was really a second generation Lisa, so they had an opportunity to improve on a lot of things. In some cases, a step was made backwards.
Signal: What’s an example of Macintosh taking a step backward?
Signal: What was your influence on MacPaint?
Signal: Why did it take so long for LisaDraw and LisaProject to migrate to the Macintosh and become MacDraw and MacProject?
Signal: You say that like you’re hinting.
Smith: It’s sort of like a hint. I know of some outside developments in that area, outside of Apple. There are a couple of efforts going on there. I wouldn’t be surprised to see something like that fairly shortly.
Signal: Switcher and the desk accessories have always seemed to be somewhat desperate attempts to give the Macintosh a Lisa-like environment. Couldn’t Andy Hertzfeld have made Switcher juggle multiple applications on the screen at once? It’s already executing any application on demand, but idle applications are kept off-screen. What if the Switcher’s multiple screens were shrunk down to icons and saved on a visible background, or occupied windows that could be scaled and overlap? The Macintosh could still jump between applications, and yet the user could see all of them on the screen simultaneously.
Smith: I’m not sure if that particular idea was around at the time, but Andy’s initial goal was to just do something simple, and that had the highest chance of success. Switcher seemed a fairly simple idea, although it turned out, because of the Macintosh architecture and the system design, to be quite difficult to do. It really took someone with Andy’s intimate knowledge of the low level aspects of the system to pull that off. However, now that Switcher has been done, and it’s been shown it’s possible, we will see more Lisa-like models, where the visual continuity is retained.
Signal: Where do you see the user interface going? What will future products look like?
Smith: What we’ll see in the long run, in terms of software products anyway, is a much tighter integration. You’ll be able to buy small tools that fit into the rest of the system and work in combination with all other tools. Say, for example, you’re trying to compose a memo to someone. In front of you is your piece of paper in electronic form, and you’re typing or writing on it. You want to do something like check the spelling of a word. Rather than necessarily invoking the spelling checker built into the word processing program you’re using, you simply use the spelling checker you purchased the other day. It would be tightly coordinated with the overall system, so you could take that tool or any other tool and use it to operate on the document you’re currently working on. What it’s going to take to do something like this is a real solid low-level system design that provides a common data structure format everyone can plug into and that provides very easy access to all data on the system, whether it’s a picture or a document or a database or whatever. Some sort of uniform style, such that any tool that’s around can be used on any document. Some of that has been done to some degree with systems like Smalltalk, but nothing in any commercial sense.
Signal: What gets rid of the mice? Voice?
-- ----- You received this message because you are a member of the LisaList group. The group FAQ is at http://lowendmac.com/lists/lisa.html To post to this group, send email to lisalist_at_email.domain.hidden To leave this group, send email to lisalist+unsubscribe_at_email.domain.hidden For more options, visit this group at http://groups.google.com/group/lisalistReceived on 2015-07-15 16:47:07
This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:15 EST