The LisaBar – or – Why Apple got it right.

In my new job I’m constantly forced to use Microsoft products. And while I have to admit that those products offer some quite astonishing features that can really easy your life, I constantly run into one or another wall, leaving me dazed and making me scratch my head. One of those walls is Microsoft’s inability to decide whether to use SDI or MDI.

The single document interface (SDI) is the user interface paradigm where each document consists of a single window, including its own tools and menu bars. If you have to use/view/edit multiple documents of the same type, each of these documents sits inside its own window, giving the impression that multiple instances of the application are running beside each other, even if that may not be the case. One major drawback of SDI is the increased need of screen estate; since each window has its own controls, those controls take up more space. (And no; bigger screens are no solution to that. But more of that later.)

The multiple document interface (MDI) on the other hand places all document inside a single parent window, creating the illusion of a document workplace. All document use the same toolbars and menubars. The big disadvantage of the MDI is the need for an additional window management interface; because the window manager does only know about the parent window, the application (or the toolkit) has to re-implement all the windowing functions usually provided by the window manager; window placement, window selection, window management.

Now in its long history the Microsoft Office suite has had many changes. And a lot of those changes revolved around the question whether to use SDI or MDI. In the beginning, MS Office used SDI for all its components. Then it changed them to MDI, and finally back to SDI again. But to make things worse, many components have their own definitions of how a MDI or SDI should behave. Excel for example behaves like user interface hermaphrodite, showing characteristics of both MDI and SDI. This is very confusing.

The root of all evil lies within the ways Microsoft chose to design their user interface. Back in ’84, when the first version of windows arrived in the market, Microsoft took the liberty to very generously ‘borrow’ from the Lisa user interface. Now Apple did not invent the graphical user interface, Xerox did. But that’s another story. However; when Microsoft borrowed those concepts, they knew that they were on very shaky terrain. And since they didn’t want to get into a lawsuit (which they got anyway) they changed some aspects of the user interface.

On of those aspects was the unification of the menu bar and the application interface; whereas the Apple’s document interface consisted of the whole screen, Microsoft’s document interface consisted only of the documents own windows.

Microsoft Windows 1.0 - courtesy of Ars Technica

Now I don’t know if Microsoft’s engineers knew what a mess they created. But by unifying toolbar and document window they created a visual ambiguity; where Apple’s interface enforced method and conduct, Microsoft’s concept created a distinction between screen and workspace. All of a sudden, the screen consisted of multiple workspaces, one for each document. And while some may, somewhat rightfully, say that this improves usability because it ties the tools to the document, it has one big drawback; all of a sudden the application is in the center of the user interface, not the document anymore.

The Lisa user interface - courtesy of

People working with Apple computers are used to a very consistent user experience. For a large part this stems from the fact that the Lisa type of GUI does not have to fight with MDI vs. SDI. The question simply never arises, because the Lisa type of GUI does not offer the choice to create either of both; it’s something different all along. I usually think of it as ‘MDI on steroids unified with a window manager’. It virtually includes all benefits of a SDI and and the benefits of an MDI.

First of all, it saves a lot of screen space. Because the additional menubars are no more than optical bloat. “But,” you may say, “screen estate is not so important anymore. Screens get bigger and bigger, with higher resolutions and stuff.” Well, yes. But the human visual sensory equipment has limits. There is a limit of how much information you can get on a area of a certain size. And there is a limit to the area the human eye can usefully overview. And while there are people that are working with two, three or more screens, this is only the exception.

Another advantage is the document-centric approach the Lisa-type GUI takes. Documents, not applications, are the center of the desktop. No matter what kind of document you’ve opened, it never feels like you’ve ‘started’ an application. It never feels like you are using an application, rather the document itself seems to be providing the necessary tools.

The Lisa-style interface has also the advantage of the window manager knowing about all windows. There is no distinction between document windows and in-application-document windows, simply because there are no mechanisms to support such a separation; it’s policy by design. And because all windows are handled by the window manager, there are no requirements to implement such things on the toolkit or application level.

Last but not least there is Fitt’s Law. More properly termed; Fitt’s Rule. There have been many discussions about how much Fitt’s Law really applies. But in the long years I’ve been using graphical user interfaces, the rule has proved itself many times, again and again.

Microsoft may have recognised the folly of their action back in the ’80ies; Microsoft’s Office 2007 suite behaves very much like a Lisa-type user interface when in full screen. But only if in full screen. And they are constantly trying new user interface concepts. The new Internet Explorer hides the menu bar in the default configuration, don’t be surprised if it re-appears on the top of the screen in Version 8. And the new Microsoft Office 2007 plays with a interesting new concept; Ribbons. Maybe they’ll come up with something new altogether, who knows.

9 comments so far

  1. ekerazha on

    As I’ve already said here

    “I think the application menu is an application thing and should be inside the
    application window. This mac-style approach is just wrong and illogical imho.
    Moreover it looks unsuitable if there aren’t maximized windows, if the
    application doesn’t have a menu bar or if it has a complex structure with
    multiple bars.”

    I agree on the disadvantages of the current MDI approach, but the “LisaBar” one isn’t much better imho: as I’ve already said, the application bar should be inside the application window because with the “LisaBar” I’ve “always on top” useless and wasted space when there aren’t maximized windows or when the application doesn’t have a menu bar. This is really wasted space, worse than the filled menu bar (*if any!*) of a SDI application. Applications bars have sense inside the application window and context. Moreover, if I have an application with a complex structure and multiple bars, the “LisaBar” creates a fragmented environment with things inside the application window and things outside the application window.

    I think a good approach would be to have a “WM-wrapper”, where I can have a sigle form with its bars (if any) or more windows (MDI-style I could say) but managed by the WM.

    My two cents (and excuse me for my bad English).


  2. Richard C. Danek on

    Generalization are, in general…nevermind. I never did remember how that joke-line went. My thoughts on this are, however, that I get suspicious with generalization that drive a GUI because I’m unique. What would be better? How about an option. In the Mac GUI, I would love to see an “option” where I could doc the appropriate menu bar onto the active windows. The options could even be that the single top-of-screen bar disappears as it’s re-docked, or simply gets cloned onto the active window.

    Why? I use two monitors. When the active window is on one, I have to mouse way over to the other. That’s just dumb.

    I’m not saying one way is better than the other. That’s a generalization. I’m saying choice is better than no choice. We’ll that’s a generalization, too, but I think one that’s easier to defend.

  3. Liam Proven on

    Interesting piece but it feels incomplete.

    I have several reservations, though.

    [1] How come you talk of the Lisa interface but illustrate it – and mainly seem to discuss – the Mac interface? They’re not the same. They’re not even that similar. The Mac is application-based and driven.

    [2] I disagree that the Mac is MDI of any kind. It is SDI, pretty much, with a unified menu bar.

    [3] Fitt’s law is very widely taken as some kind of axiom or biblical pronouncement; you are not the first. It’s not; it merely reflects a certain type of bias. For instance, there is a simple, obvious menu placement method which is more efficient than Fitt’s edge-of-the-screen-as-biggest-target rule. That is, the context menu. Look at old Unix systems – back in the days of OpenLook and so on. More saliently, before commenting on such things, I feel that you really need to play with one of the first mass-market WIMP GUIs that was truly multitasking: Acorn’s RISC OS. It’s still being developed and sold. It refines the Unix-style 3-button mouse paradigm into near perfection; there are no fixed menu bars anywhere, and no need for clumsy kludges like mice with scroll wheels, “OK” and “Apply” buttons and so on. It has problems, sure, but it is, in its way, considerably more elegant than either Classic MacOS or Mac OS X. Anyone criticizing WIMPs *needs* to get to know RISC OS. (I would count Atari GEM and Amiga Intuition, but I don’t think either of them brought anything genuinely new to the table. The Amiga’s top-of-the-screen global menu /that you must summon with the right mouse button/ is, to my mind, a particular ergonomic horror.)

    The most efficient menu position is the one where you *do not need to move the mouse at all.*

    Secondly, this removes one of the Mac’s nasty little niggles, which OS X preserves: that of the menu bar that randomly changes on the user depending on which window they clicked on last. This always throws beginners and can fox experts too; we all make mistakes.

    Thirdly, by having no menu displayed at all unless you ask for it, no screen space is wasted. You only get a menu when you need a menu, and because you asked for it, by clicking the menu button over a window, you know what menu you’re going to get.

    It’s far simpler and more elegant than the Apple way. Yes, a 3 button mouse takes more learning, but not much. The ideal GUI, I think, is perhaps one which has a simple one-button model for beginners which gradually shifts to a more powerful multi-button one as the user grows more proficient, banishing fixed menu bars on the way. The only tricky bit – and it’s a doozy – is working out how to manage the transition.

  4. Top Posts « on

    […] The LisaBar – or – Why Apple got it right. In my new job I’m constantly forced to use Microsoft products. And while I have to admit that those products […] […]

  5. Pug on

    Those system 6/7 era screen shots bring a tear to my eye.

  6. mac on

    Congrats Liam!

    The most efficient menu position is the one where you *do not need to move the mouse at all.*

    Secondly, this removes one of the Mac’s nasty little niggles, which OS X preserves: that of the menu bar that randomly changes on the user depending on which window they clicked on last. This always throws beginners and can fox experts too; we all make mistakes.

    That’s what i always thought.

    Let me ask a question:
    Hasn’t Apple changed some details in the interface of Mac OS X? Or has it remained totally stable (i don’t think so)?

  7. Ted on

    You can argue the merits of both styles, but the real measure of which one is “better” can be made with this question: Which method makes it easier for the user to learn the application?

    In theory it really wouldn’t matter much, so long as a new application followed the previous applications rules in the menu arena. However, because Apple forced the main menu bar on every app, and Microsoft made it application specific, an odd thing happened. Mac developers tended to stick the HIG and ensure that menus and their keyboard command equivalents remained constant. Apple-S saves, Apple-P prints, Apple-W closes Windows, and so on. Microsoft, on the other hand, lets each app decide which menu arrangement and keyboard shortcuts it uses.

    So if a Windows developer wants to assign Ctrl-P to Preferences, they are more than welcome to. And many (not all, but a good number) would do something as dumb as that. Case in point – Microsoft themselves break “Ctrl-W” usage for closing a Window in Outlook.

    So which is better. Well, if I can rest assured that the menus/keyboard commands of open, save, print, cut, copy, paste, preferences, close window, select all, find, find again, and so on are going to be consistent from app to app, I know that out of the box I can learn 60% of an application just by knowing the base keyboard commands. On Windows, you can’t say that.

    As to the people that say a changing menu bar throws people when they change from app to app when they first use it… Well, that is true, but only of users who come with a Windows experience. People who have never used a computer before (or haven’t been numbed by the use of Windows day in and out) appreciate the consistentcy in the menubar alway being in the same exact spot for each app, and always have the same commands for the applications core functions.

  8. James on

    For single tasking, the Lisa interface looks OK.
    For multi-tasking, the MS MDI is better.
    MS provide SDI for single tasking and MDI for multi-tasking.

  9. びっくり on

    If the most efficient menu position is the one where you don’t have to move the mouse, doesn’t that imply that it is most efficient not to use the mouse? I definitely prefer a menu system that can be accessed without removing my hands from the keyboard. My right can easily reach about 24 keys on the keyboard, but only 1, 2, or 3 buttons/wheels on a mouse.

    When the trend to add more buttons to devices was popping up almost 20 years ago, I suggested the 55 button mouse. Partly it was a joke at the expense of the common trend, but with laser mouse technology we could turn the keyboard into a mouse. This would provide mouse pointer capability without removing a hand from the keyboard. Downsides = needs a little real estate on the desk, some users couldn’t adjust, no good for laptops.

    Better still, divide the keyboard in two between 5TGB and 6YHN and make the right piece into a mouse. Slightly dish the key surface and all of the keys move a little closer to the hand for ease of typing. Yes, a little wacky, but maybe useful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: