Why not MDI?

This question comes up fairly frequently, so I figured I'd take a few moments to explain why you should never use MDI in a new application. To truly understand why not, you have to first understand "why" -- so I'm going to give you a brief history lesson.

Rewind about 20 years or so to the pre-Win9x days. At this time, the OS wasn't preemptive-multitasking (it was cooperative), which meant that switching between processes could be a dangerous thing. If the process in the foreground was hung, the whole machine was hung. What's more, the process in the foreground was the one actually "doing things" -- items in the background were content to wait until the user switched back to them. If your application had multiple documents in it, this could be a dangerous place. The user may try to switch to another window in your application with the mouse, and hit a totally different process' window -- and halt everything that's going on in the other processes. What's more, there was no task list telling you about what windows were open on the desktop. The user had to use the mouse to play this sort of "guessing game" as to which window does what. It was a mess!

Along came this concept called MDI. It was a really clean solution to the problems of a multi-document application on a cooperative system. You had a unifed window which was responsible for keeping track of all the documents active in the application. When the user wanted to switch to another window, there was no more hunting! They simply went to the Window menu and picked the one they were after. What's more, since all of the document windows were enclosed by the parent frame, there was little chance of the user accidentally bringing another application to the front. It was a great way for an application to "take over" the user experience in a simple fashion. Back then, MDI was useful.

Bump back foward a bit to August, 1995 when Windows 95 was just released. Now the landscape of the OS had changed drastically. Gone were the cooperative scheduling problems of yesteryear -- all applications now ran in a preemptive multitasking operating system (with their own address space, no less!). You had 32-bits of address space instead of a measly 16 bits. In just a few short years, you could hook up to nine monitors up to your computer! You had a taskbar.

All sorts of changes happened -- and many of them rendered the MDI dream useless. Sure, you could still *use* MDI if you wanted to (since it continued to work). However, the reasons for using it were entirely removed. What's more, the reasons against using it were mounting, and quickly.

Since the OS was preemptive, the whole worry about cooperative applications hogging the resources away from your application were gone.

The OS now had a taskbar which showed you all of the open windows in the OS. The Window menu for MDI was rendered obsolete. What's more, when the user did open an MDI window, they now had *two* places they had to look for open windows! Not only the Window menu of the MDI frame, but the task list.

While Alt+Tab had been around since Windows 1.0, no one knew about it aside from the occasional power user because it was an entirely hidden OS option (you even had to turn the functionality *on* in some versions of Windows!). However, Windows 95 started making heavy use of it -- it was on always, well-documented, and totally useless with MDI windows. The user had to remember to hit Ctrl+Tab (which was still hidden, and still is today) to switch between MDI windows. As if anyone remembered to do that!

So all the reasons for using MDI have been removed, and you can see some of the reasons for not using MDI started to appear. But there were even more reasons than that! With Windows 98 came the ability to hook up multiple monitors to your machine. Now, with an MDI frame, the user is totally hosed. That frame can only be *stretched* across multiple monitors, which makes their use less than ideal. At this time, Microsoft started telling people designing new interfaces to stop using MDI. The UI concept had outlived its usefulness.

This isn't a new concept -- other UI controls have gone the same was as MDI. IP address fields are no longer a good idea to use (most people prefer DNS, but you also have IPv6 proliferation to worry about as well). The "animation control" has been relegated to a dusty closet. And so on.

So if you want Aaron's complete list of reasons why not to use MDI (in no particular order):

• It's a dated UI -- it makes your application "feel" old. That's because the concept was designed for a user experience that's over 20 years old. So not only does it make your appliation feel old, all of the useful qualities of the concept are gone.
• It requires more thinking on the part of the user. Ctrl+Tab, not Alt+Tab to switch between windows. The Window menu instead of the task bar. The base of the frame instead of the task bar when minimizing windows. And so on.
• It retards the power of multiple monitors being used for a single application. That MDI frame basically ties you to a single monitor, or it totally negates the usefulness of multiple monitors if you try to stretch it. Some folks will tell you "just use floating palettes then -- they can be moved to another monitor." Don't listen to them -- floating windows have an entirely different set of usability issues.
• When you use MDI, locusts will eat all your crops. Ok, I just made that one up, sorry.

So, the next time you say "I'm making this MDI application, and.." remember -- just say no. MDI is more detrimental than useful, and you should avoid it when designing new user interfaces.