MDIs on the Mac

Way back when the first graphical user interfaces were created, Apple and Microsoft went similar ways. Both used the desktop metaphor with files and folders, both had overlapping windows which showed documents and folder contents. However, they also took different paths for a few fundamental UI concepts. Apple had the “always on top” menu bar, while Microsoft put the menu bar inside windows. Apple went with an application-centric model, where each application could only be launched once but have many windows, while Microsoft went with a document-centric approach, where applications would sometimes launch multiple times.

The Multiple Document Interface

Apple very strongly went with the idea that each document corresponds to exactly one window, while Microsoft introduced a concept called the “Multiple Document Interface” (MDI), which allowed applications to have hierarchical windows: document windows reside under a parent application window.

MDIs have some advantages; they naturally help reduce clutter by grouping windows. They make it easy to hide all windows for a given application. If you tend to use applications in full-screen mode, having a MDI makes sure you really only see the active application and no other application.

Either way, Mac applications never had MDIs.

The times, they are a-changing

Mac applications used to have many windows. Recently, this has started to change, mainly due to Apple’s influence. Mac applications such as iPhoto, iTunes, iMovie, Aperture or iDVD tend to only have one window.

However, these applications do not have MDIs. Neither of these applications are multi-document applications. They are either media managers (iPhoto, iTunes, Aperture), or they are typically used to open only one document at a time (iMovie, iDVD).

MDIs on the Mac

Unfortunately, some companies have taken Apple’s new one-window-approach to UI design as a hint that they should introduce MDIs (or an MDI-like approach to UI design) on the Mac. Nolobe’s Iris, otherwise a very capable program, is such an application: Note the list of open images in the bottom row of the single window.

Adobe’s CS4 applications will also use MDI on the Mac (albeit only optionally - one can only hope that it will not be the default choice): Note the tabs above the image.

MDIs on the Mac are generally a very bad idea.

So why are MDIs on the Mac a bad idea?

Glad you asked. There are many reasons why MDIs are a bad idea; some of them generic, some of them due to how the Mac normally works.

Why MDIs are bad in general

Please note that these lists are not exhaustive; also, not all of these points apply to all MDI applications. To name one example, Adobe has gone to great lengths to make sure their MDI would work around almost all of the issues in this list.

• Most modern computers support multiple screens, and a lot of people make use of this feature. MDIs don’t support multiple screens; since all of your documents are inside one window, you can’t put one document on one screen, and another document on another screen. Note that in the CS4 UI, it’s possible to pull document windows out of the main window, so this criticism does not apply.
• MDIs often make it hard to compare several documents belonging to the same application, or to view them side-by-side. CS4 supports tiled views to allow for this.
• MDIs make it hard to drag from one document to another inside the same application. In Photoshop, dragging layers between applications is something I do daily. MDIs make this hard (or even impossible, depending on the implementation), and force the user to copy-and-paste instead. Adobe’s CS4 UI supports spring-loaded tabs, which isn’t quite as good as direct drag-and-drop, but should be a workable solution.
• Some implementations of MDI make it hard to remove palettes from the main window. This is bad because in a multi-screen environment, a typical setup is to move all palettes to one screen, while keeping documents on the other screen. Again, the CS4 UI allows for this, so no complaints here
• MDI takes away space on larger screens. After your screen reaches a certain size, it doesn’t make much sense to maximize windows anymore. Having an MDI means you always waste space with a ton of application chrome around your documents - space which could be used by other applications running at the same time. Again, CS4 has a solution for this; hitting tab removes the application chrome (although I wasn’t able to get it back easily - hitting tab again did nothing at all). Unfortunately, the application chrome is not hidden if the application is put in the background while in MDI mode.

Why MDIs are especially bad on Macs

As if these reasons were not enough, there are a few additional reasons unique to Macs:

• MDIs break Spaces. You can’t have one document in one space and another document in another space if all documents must reside inside the same window.
• MDIs (including tabbed browsers) break Exposé. This is what happens when you activate Exposé in Fireworks when the MDI is active:

Obviously, it’s entirely useless. This is what happens with the MDI turned off:

Much better.

By the way, Adobe, “zoom to fit” is currently broken and maximizes windows instead of zooming to fit their content - yet another Windows behaviour that has no place on the Mac. Also, the little “this document contains unsaved changes” dot in the close button does not work, which is probably another result of the MDI; UI elements don’t need to look the same in all apps, but if they look similar, they need to behave the same so as not to confuse users.

What Adobe did right, and what they did wrong

Adobe actually implemented workarounds for most issues I list. However, they are often non-obvious. Furthermore, if other applications with MDIs try to fix these same issues, they will most likely find different solutions, creating an inconsistent user experience.

Since there is no history of MDI applications on the Mac, and since Apple doesn’t have anything similar to these applications, there are no established UI guidelines. Hence, MDI-based applications confuse users since they behave inconsistently with each other.

Replacing an obvious, consistent solution to a problem with a non-obvious, inconsistent solution is generally a bad idea, unless the new solution is shown to be considerably better than the old solution (as an example for this, check out the Ribbon UI in new versions of Word for Windows - it’s non-obvious and inconsistent with other Windows apps, but it’s so much better than earlier versions of Word that the change is worth the issues it causes).

In this case, consistency with the host OS and its applications seems a lot more important than consistency with different versions of the same application.¹ In my opinion, the Mac version of Photoshop should look and (especially) behave like a Mac application, rather than like the Windows version of Photoshop.²

I should point out that I don’t have access to Adobe’s UI test results. One would hope that they did usability tests and found that the new UI is much more usable for Mac users than the old one before deciding to go with the MDI UI on all platforms. If so, changing to the new UI is the right thing to do.

Apple is to blame, too

Apple itself has at least one document-centric MDI application, too: Safari. The fact that Apple has an application which uses tabs to switch between several documents inside one window is probably partially to blame for the recent third-party enthusiasm for MDI apps on the Mac.

Originally, tabs were not meant to switch between documents. They were meant to organize “things” (such as settings) into groups of similar “things”, or - at most - to switch between different views of the same document. Not so switch between different documents.

It is kind of unfair to blame Apple for introducing tabs in Safari - after all, users demanded the feature, and Safari’s tabs are turned off by default (something other developers should copy if they insist on bringing MDIs to the Mac). It’s just very unfortunate Apple’s choice helped usher in a new era of MDIs on the Mac.

Conclusion

MDIs are bad news on the Mac because they break a lot of behaviours Mac users are used to. They should be avoided.

Addendum: John Nack replies to my blog post (scroll down to the comment linking to this post). He points out that most of my criticism of MDIs doesn’t apply to the CS4 UI since it’s possible to have (tabbed or single) windows outside the main window (Admittedly, I noticed this while trying the Fireworks prerelease, but actually thought it was due to a bug because I wasn’t exactly sure how I ended up in this state).

He furthermore thinks that it’s Apple’s fault for not giving developers a way of supporting Exposé for tabbed windows, with which I agree; still, Apple doesn’t force anyone to create interfaces which don’t support Exposé :-)

I’ve updated this post to reflect the fact that CS4 provides solutions for most issues MDIs normally cause.

Addendum 2: I mistakenly claimed that Final Cut Pro was a one-window application. This is false: I have not used FCP in a while and misremembered how its UI works. While FCP looks like a one-window application, the different areas of the UI are actually individual non-standard windows. Thanks to Ben De Rydt for pointing this out to me.

Addendum 3: Mike Lee, the world’s toughest programmer, disagrees with much of what I write, essentially saying that the concept of an MDI is not in itself flawed, but that it’s a question of context (how is the application in question used?) and implementation. He makes some good points, and furthermore calls me “chef,” so I recommend that you read his post. Also, who wants beef with the world’s toughest programmer? Not me!

I do have to take exception with two things he says, though.

He claims that it is false to differentiate between media managers and document-based applications. He does not, however, explain why this is false, except for pointing out that both Photoshop and iPhoto work with “media.” However, iPhoto is not a media manager due to the fact that “the documents in question are media.” iPhoto is a media manager because its main use is in managing your data. Faulting a media manager for having multiple documents in one window would be akin to faulting the Finder for allowing more than one file in a folder: In the application’s model, you are typically working with representations of your documents, not with the documents themselves.

Then, just after writing that “nobody likes Adobe,” Mike claims that I did not use Photoshop as an example “because people like Photoshop.” This is not why I used Fireworks. I went with Fireworks instead of Photoshop because I do not have access to a Photoshop beta, only to a Fireworks beta. The two share the same user interface, so any criticism I have made applies to both applications equally.

June 7th, 2008 / Tags: MDI, UI, usability, HIG, Apple, Iris, Nolobe, Adobe, Photoshop, Fireworks / Trackback

Apple's Photoshop Killer

Three days ago, Adobe announced that Photoshop CS4’s 64-bit version will only be available on Windows. There won’t be a 64-Bit version of Photoshop for the Mac until CS5.

How Mac OS X came to be

First of all, I want to make it perfectly clear that this is not Adobe’s fault. Apple has brought this upon itself, and to understand how this has happened, we need to go back a few years to the time befor Mac OS X. In the early 90s, Apple was in a bad position. Its operating system was technically outdated. Several projects inside Apple, and several joint-ventures with other companies aimed at creating a successor to Apple’s operating system had failed. Apple was essentially forced to either buy an existing solution, or license an operating system from Microsoft or Sun. Apple didn’t want to become dependent on a third-party operating system, so they had to buy an OS. At the time, there were two options: Be’s BeOS and NeXT’s OPENSTEP. Apple bought NeXT in 1997, bringing Steve Jobs back to the company as well as giving it a new operating system.

Soon thereafter, Apple announced its plan: Developers were basically forced to rewrite their applications in Objective-C for NeXT’s object-oriented, comparably modern APIs and frameworks, or “Cocoa,” as Apple called that part of what would become Mac OS X. Third-party devs were understandably not pleased at all. In particular, Apple relied on two third-party applications: Microsoft Word and Adobe Photoshop. Without these two applications, Mac OS X would be stillborn. Given Apple’s financial position at the time, chances were they could not survive such a disaster.

The Plan

Microsoft and Adobe must have made it pretty clear to Apple that they were not going to rewrite their applications for Cocoa, because soon after its first announcement, Apple changed its tune. In addition to Cocoa, there would be a second API called Carbon. Carbon is essentially a port of the old, procedural pre-OS X Mac APIs. Using Carbon, developers could easily port their old Mac applications to Mac OS X without having to rewrite large parts of their code.

When the first end-user version of Mac OS X came out in 2001, it didn’t take too long for native versions of most important applications to come out, and all was well for Apple.

64 Bits

Today, we are looking at a similar transition as the one from Mac OS 9 to Mac OS X, albeit on a different level. For the last decade, most computers used 32 bits to address blocks of data in memory. Since each address has a fixed length of 32 bits, the number of individual addresses is limited. As memory has gotten bigger and bigger, computers are starting to run out of addresses for the individual blocks. To allow computers to address larger memory spaces, they are switching to using 64 bits for each address.

To cope with these larger addresses, operating systems as well as applications have to be updated. As late as 2006, Apple’s story was that they would upgrade both Carbon and Cocoa to 64-bit versions, allowing all Mac applications exist as 64-bit versions. Adobe thus worked on a 64-bit version of Photoshop. Last June, Apple pulled the rug out from under them by killing the 64-bit version of Carbon.

This leaves Adobe with a year of wasted effort and no easy way to create a 64-bit version of Photoshop.

I want to make it perfectly clear that I do not think that Apple’s intent was malicious in any way. Recently, there has been quite some evidence that Apple’s engineering is understaffed. In order to finish the iPhone in time, Apple pulled engineers from Leopard and had them work on the iPhone, which lead the Leopard’s delay. It is obvious that Apple either simply found out that they did not have the resources required to finish 64-bit Carbon in time, or thought their developers’ time would be better spent working on something else.

So now Adobe is forced to throw away some of their work and rewrite large parts of Photoshop in Cocoa, which isn’t a small task by any means.

How can Apple afford to do this?

So how can Apple do this? Back when they moved from Mac OS 9 to Mac OS X, Microsoft and Adobe were able to force Apple’s hand. Why don’t they have that power anymore?

Apple learned a lot from that time. It’s a lot less dependent on outside developers today.

Microsoft

When looking at Microsoft, first of all it’s important to keep in mind that a 64-bit version of Office isn’t really needed. Office doesn’t have to cope with documents sized in the multi-gigabytes. Office works perfectly well in 32-bit Carbon, and will continue to do so for decades, if Apple keeps 32-bit Carbon updated.

Second, there’s iWork. While iWork isn’t a perfect replacement for Office, it works really well for many people. Today, it’s possible to use a Mac that is free of Microsoft applications in almost any environment.

Adobe

Adobe is a tougher nut to crack. While Apple has been competing with Adobe on many fronts such as video editing or photo management, they don’t have a Photoshop killer.

What Apple has been doing for the last few years, however, is create APIs that make it easier to create Photoshop-like applications. Using Apple’s Core Graphics frameworks, developers can create rudimentary graphics applications within days, and even small teams can create applications that, even today, can replace Photoshop in many cases. Pixelmator, to name one, was created by one single developer and one single user interface designer. Even in its first version, it does many things that Photoshop does. It even does a few things Photoshop doesn’t do. More importantly, it is improving quickly. While Pixelmator currently still lacks many features Photoshop users take for granted, there are new Pixelmator versions with more features almost monthly.

Here’s another thing Apple has done: Its popular photo management software Aperture now supports plugins. There is nothing stopping a third-party developer from adding an image editor with many of Photoshop’s features right within Aperture.

As Apple continues to improve its graphics frameworks, it won’t need to create its own Photoshop competitor, because it will have an army of third-party Photoshop competitors.

This, I think, is why Apple was able to simply kill 64-bit Carbon: For the last decade, it has worked hard on becoming less reliant on Microsoft and Adobe. Delaying the 64-bit version of Photoshop by a year or two won’t hurt Apple at all.

April 5th, 2008 / Tags: appler, aperture, photoshop, lightroom, mac os x, mac os 9, carbon, cocoa, adobe, microsoft, word, iwork, iris, acorn / Trackback