Communication with the user: some examples from the Lisa

In the past days I’ve been tinkering with the beautiful LisaEm, probably the best Apple Lisa emulator around (I’ve already mentioned it in this blog, by the way). After installing the various tools of the Lisa Office System (LisaWrite, LisaDraw, LisaGraph, LisaCalc, LisaList, LisaProject, LisaTerminal), I started exploring them, using the emulated Lisa 2 as if it were a real computer, and taking notes about the interaction with the operating system and the user experience.

I won’t be talking in depth about the history of the Lisa, because it’s not the point of this post. The Macintosh and the Lisa user interfaces had a lot of similarities, but were also quite different, especially regarding the communication with the user. I have used early versions of the Macintosh OS, as early as System 2 if I recall correctly, and I’ve been using regularly every Mac OS version from System 6 to the current OS X Snow Leopard. By using the emulated Lisa for a couple of days, the first thing that struck me has been how thoughtful and literally user-friendly the Lisa Office System interface is. I daresay it’s even more user-friendly than the famous Macintosh GUI.

Let’s take a small visual tour. (Note: the images are a bit shrunk and you’ll have to click on them to see a better reproduction of the screenshots).

This is how the Lisa Desktop looks with the seven main applications (called Tools in Lisa’s parlance) of its office suite. Note the Empty Folders folder. In the Lisa operating system, there wasn’t a command to create a new folder: you just double-clicked on the Empty folders folder and a fresh, empty folder (named Empty Folders 11/14 — that is, today’s date is appended to the name) was created. This is not surprising, since the whole Lisa system is document-oriented, not application-oriented like basically every other OS around, then and now.

In Lisa’s specific desktop metaphor you would have a new folder by going where all the empty folders are and picking one, pretty much like a real office environment. The same would happen upon creating a new document using any of the seven aforementioned main applications. To create a new text document you don’t open the application LisaWrite (as you would do in any application-oriented system). If you do, Lisa would react this way:

“LisaWrite stationery?” you might ask. Yes, in every Lisa office Tool folder, along with a subfolder with a sample document and the Tool icon itself, there’s also an icon named [Tool name] Paper, in this case LisaWrite Paper. This is the stationery mentioned by the previous message. It works like the Empty Folders example we saw above. To create a new LisaWrite document, you double-click on the LisaWrite Paper icon and voilà, a blank text document appears in the folder, with the standard name convention LisaWrite Paper [today’s date].

Of course you can rename it as you see fit, and double-clicking it you’ll actually open the LisaWrite application. It may seem a little convoluted to our application-oriented habits, but I find its logic compelling and consistent. It’s a behaviour that was perceived as more natural by the people who designed the Lisa UI. In the real world, when you begin a new document, such as a personal letter, you don’t expect the pen or the typewriter to create the writing space, the template, for you. You take a piece of paper (and it might very well be a piece of dedicated stationery: a sheet with the company logo for a work-related document, or special high-quality letter paper for personal correspondence, etc.) and then you use the other tools to actually write that document.

With the Lisa, it’s the same. You want to create a spreadsheet? You tear off the specific template for it, which is a LisaCalc Paper, and you’ll be offered all the necessary tools to create and manage that spreadsheet inside the LisaCalc tool environment. You want to start doodling? Tear off a LisaDraw Paper. And so on.

Back to user communication. In my brief experience with the emulated Lisa, I noticed how the Lisa operating system presented better-worded warnings and error messages which were less obscure and potentially more useful than other systems, Mac OS included. Here’s an example. The LisaWrite application and its files came on two diskettes. To copy the contents of the diskettes in the Lisa’s ProFile hard disk, I inserted the LisaWrite 1 diskette, selected the icons and just dragged them on the empty LisaWrite folder I had prepared before. Coming from a long-time experience with the Macintosh user interface, that seemed the most intuitive thing to do. I didn’t know that on the Lisa you have to duplicate (D) the selected icons and move the blinking duplicates Lisa creates, instead of the original files. I also did not know that the American Dictionary included with LisaWrite was actually split between the two floppies (since it was too big to fit on one), and that I couldn’t just copy the first part along with the other files.

How would the classic Mac OS — or even the modern Mac OS X — deal with such a situation? Probably by displaying something like Error: Cannot copy American Dictionary in (target folder) or American Dictionary could not be copied in (target folder) and offering the [Stop] and [Continue] buttons, without giving much insight to the user regarding what just happened. Often the user would also like to know why a certain attempted operation has failed. Lisa helpfully reacted this way:

That dialog box is surely verbose for today’s standards, but it gives real information, and a useful, direct reference to the user’s manual so that we can understand what happened. You have to consider that such design for dialog boxes and error warnings was conceived in an era when users actually took notice of such warnings. From thence, it’s been a road downhill, also thanks to more brief, confusing and unhelpful error messages. Remember the coded error messages of the classic Mac OS? Sorry, a system error has occurred. (Error -11) Not useful at all. Not trust-inspiring, either.

Back to the American Dictionary impasse, I didn’t have the Lisa Office System manual at hand, but in the Lisa FAQ section of the LisaEm website, I found the answer:

[…] Note that you cannot mix and match normal files with files that are split across several floppies (such as the American Dictionary on the LisaWrite floppy.) Instead, you’ll have to first duplicate the normal files manually, and later transfer the split files. When copying a split file, the Lisa will eject the floppy and ask you for the next floppy to retrieve the next piece of that file. […]

Following the instructions, all went well and the Lisa kept me posted on the current state of operations:

It’s worth noting that the Lisa could automatically split large files and archive them on many 400K diskettes, and reconstruct them later when needed. It didn’t need additional tools or utilities like StuffIt or UnRAR. Thus, backing up the data in the hard disk on a series of floppy diskettes was very easy: you just dragged the hard drive icon on an empty floppy icon and the Desktop Manager would ask you for another disk, and then another, until it reached a full backup.

Another interesting aspect of the Lisa Office System is that it copy-protected applications and documents by giving them unique serial numbers that would tie them to a specific Lisa unit. So, when copying the various Office Tools from the diskettes to the ProFile hard disk, I received this warning:

Again, notice how well-written and informative this warning is. It is very clear about what’s going to happen, so that the user can make an informed decision.

Another example: I was manipulating an example list in the LisaList tool, and made changes in the formatting, order and font used in the list. Suddenly the screen went blank, as if the application had crashed or something. But soon the Lisa informed me about what was happening with another exhaustive dialog box:

I love that expression, “[The tool] is having technical difficulties”: it is clearly an example of an era when the personal computer was starting to spread among regular, non-tech users, and this warning sounds sort of reassuring, as if to say: there is a technical problem, I won’t confuse you with the details right now, but I can attempt to solve it, and here’s a reference in the User Manual that may help you understand what’s going on.

I’ve also encountered a couple of funny warnings. The first one occurred when I attempted to set the date correctly in the Clock desk accessory. The time was displayed OK, but the date was set to November 12, 1987. So I clicked on the date and entered 11/12/09, but alas, I discovered that…

So the Lisa was not Y2K compliant, and the date range limited to 1981-1995 (why not 1999, by the way?).

The second warning that made me smile was when I fired up the Calculator for the first time:

But in the end this is just another example of how the communication with the user was taken very seriously by the people who designed the Lisa GUI. The Calculator could have been launched in the default mode without telling anything to the user, but this warning tries to be informative and friendly anyway. It’s not strictly necessary, but it’s a nice touch.

These are just a few examples and by no means exhaustive, but I think they’re enough to give you an idea. In my interaction with the emulated Lisa I found many other nice touches in the dialog boxes and, generally, in the language used by the Lisa’s interface. (I like, for example, the choice of terms used for certain menus and commands: Housekeeping may make you smile as a name for a menu in the main desktop environment, but it’s more clear and effective than the generic Special menu you’ll find later in the Macintosh Finder. And the command to rearrange icons and snap them to the grid was a more colloquial Straighten up Icons than a neutral Arrange icons). This is an interface which showed, or attempted to show, some true respect for the user dealing with it. Today’s graphical user interfaces might be slicker and more intuitive, but I think they leave a lot to be desired as regards to notifications, warnings, and error messages. Too often the user is left guessing what caused a problem. Moreover, too often the user is left guessing what the warning means in the first place.