I seem to be fielding a large number of people who are using MDI on Windows. I usually find out about them because they ask how they can bring that to Linux, or the Mac.
There's no really nice way to put it -- you need to rethink your user interface. This isn't some grand scheme to make your life hard. It's not some conspiracy to keep you from porting to another platorm. It simply is a bad idea. Even on Windows.
Mac and Linux do not have the concept of MDI. You can hack it, or you may have found others who've hacked it. But it's not officially supported, nor is it wanted. It isn't even wanted on Windows!
Usually, at this point, people then ask "well if it's such a bad idea, then why is it even an option on Windows?" My retort is that it's not an option on Windows. It's a conventionally deprecated feature of the OS which remains for backwards compatibility. Sure, it's not officially deprecated by Microsoft. Sure, it's still supported by the OS vendor. Guess what -- so is sysedit! No, really -- try it. Hit WindowsKey+R (to bring up Run) and type "sysedit" (without the quotes) and hit enter. Just because the option exists doesn't mean that people should be using it! Sysedit isn't the only ancient application still installed on Windows -- progman is still there too.
In case you're still not convinced that MDI is a terrible UI for your application... In case you still feel the need to point to certain pieces of software which use MDI... let me point out some facts for you.
1) When Windows 95 was released, Microsoft officially deprecated use of MDI and said it was going to be yanked from the OS. They've since retracted the "yanking" part since that would break old code. But they strongly discourage use of MDI. So even on the platform which spawned MDI, the OS vendor is telling you not to use it. No, really -- read all about it in the Windows User Experience docs. They devote five paragraphs to explaining why MDI is not a good choice. In fact, in their FAQ about whether you should use MDI or SDI, they explicitly state that you should always try to use SDI.
2) MDI is terrible for multiple monitor support. Due to the nature of the frame, there's really no good way to interact with MDI on multiple monitor systems. It just plain old won't work well.
3) MDI constrains your work area. The user cannot see what's behind your MDI application because it takes up so much screen real estate. This was fine in Windows 3.1 when you could only have one app running at a time (it wasn't a preemptive multitasking system). But for the last 10 years, it's not been a good way for a user to work.
4) MDI confuses users because it's the odd-man-out. You can't alt-tab into a MDI child window. MDI child windows don't show up on the task bar. Things like this make MDI very frustrating to use. People who aren't comfortable with computers are confused because it works contrary to the way "everything" else works. People who are used to computers are annoyed because standard shortcuts to navigate the system are useless.
There's simply no pleasant way to say this, so I'm going to be blunt (this isn't for the faint of heart): if you have an MDI interface, please stop. Please! Redesign your interface. You might think the interface "works" on Windows, but I can assure you -- it doesn't. There is no such thing as a "good" MDI application on Windows. If you are thinking of porting your app to Linux or the Mac, it's a great time to consider a UI overhaul. But even if you're not porting across platforms and just target Windows -- do your users a favor and stop the madness.
MDI does not stand for "Multiple Document Interface." It stands for "Most Despised Interface."
Good point.
Yet, for my app with lots of different types of windows, even toolbars, I have trouble seeing how to get this working in a non-MDI app. Would you care to have a look at it and advise me on this? :)
You should have grabbed me during REAL World, I would have loved to sat down with you. But doing UI consultation long distance is a PITA because it really needs discussion where we can both point fingers and use hand gestures (in a friendly manner).
how true!
My copy of Access XP is still an MDU application. O:)
err... My copy of Access XP is still an MDI application.
oh yeah... SQL Server Enterprise manager is also an MDI app. I believe it is a plugin for the Memory Management Console.
How about MDI on a VIC-20? :)
Yeah, I'm currently puzzling through how to move Tangelo away from MDI.
Oh, and I used to have to "develop" in some nasty 4D thing with a hacked up MDI on the Mac. It was really nasty.
@Christian -- just because you can find MDI apps doesn't mean that it's a good interface. ;-)
@Brad -- good luck to you!
This is one of those areas where it's usually easy for me to sit down, run through a UI with a person, and come up with ideas on how to move away from MDI. But trying to do it any other way than face-to-face is just painful. Because the fact of the matter is: you know your apps better than I do. So what I may think is a good idea for your app could be a productivity killer. So the ideas need to bounce back and forth a lot more.
All things said and done, MDI is not dead. It lives because it works. It works because it represents a document view architecture that works in certain cases. The best IDEs are MDI, (why! even RB is a MDI hack). The best browsers are MDI (why! Firefox tabs are an MDI hack). The best imaging editing software is MDI (why! Adobe photoshop is MDI).
All things said and done the concept of MDI allows you to keep similar documents/information in a single application container so that the user can be herded towards all the information.
Its always horses for courses. If the application is simple (most functionality can be exposed in a single screen with or without smaller option screens, then yes SDI is the way to go). If the application is complex (MANY dialogs or if the application is non-modal i.e. many dialogs need to be simultaenously open or if an application can be clearly represented in a document view architecture, and there is a logical grouping that is required) then MDI is the sure fire way to go (just because it isnt available in Linux and OSX doesnt exactly mean it is useless).
There may be a LOT of user interface gurus who argue otherwise, but the crux of the matter remains the same. It is a matter of choice (a choice you dont have on other platforms nonetheless).
I have been struggling to have my huge application (10 dialogs + 4 toolbars) be represented as SDI dialog interface, I dont whiich idiot would like to have 10 windows open and listed on the taskbar. It would be a dream come true if I could implement all of this inside an MDI container and have things like docking etc taken care of. (Oh! I forgot, I also needed to dock windows across different binaries, client components actually, sort of like a virtual desktop). Alas this is a narnian dream, I wish aslan would hear me out.
Cheers,
talksk
I strongly disagree. MDI is not dead because people are still copping out on their UI design.
From your examples: most IDEs have drifted away from MDI (take a look at VS.NET, RB, even XCode). Browsers are also nowhere near MDI (IE, IE7, FireFox, Safari). Image editing software, for whatever reason, still has some of the worst UI designs I've ever seen. Just because you can point out MDI applications (even ones that sell) does not make MDI proper to use. By that same logic: I can point out drug users -- that doesn't mean drugs are legal.
You seem to be confusing multiple document management with MDI. The concept of managing multiple pieces of information within a single application is not what's to be avoided. Tabs are an excellent example of a way to categorize the information (and it's only one paradigm out of many). No one is saying that you should split your application into a million little pieces that all behave independantly of one another.
What is to be avoided is the idea that you should have one main controlling frame with a bunch of actual windows living inside of it. You've already GOT that with the OS itself (the main desktop window acts as the parent to all the applications, conceptually). There's NO valid reason to replicate that idea. I used to waver on this and say "well, there could be some cases.." I waver no more -- there is NO good reason to use MDI from a pure UI perspective. Ever. You can argue that there are monetary reasons to use MDI (it's quicker to use a crappy solution than it is to use a good solution, so it's cheaper to use the crappy solution in terms of time costs). But from a user experience point of view, MDI is an aberration that is to be avoided.
Interface gurus are gurus for a reason, and to be blunt, application designer choice doesn't really matter. People spend large amounts of time and money doing research about interface design, and to outright ignore that as a matter of choice is senseless. Just because you don't see the issues does not mean the issues don't exist.
I'm thinking about jumping into REALBasic and thought I'd explore a bit... thanks for making your blog/this website a great REALBasic resource!
When I first read your post I thought, "Surely this guy doesn't just hate ALL MDI apps: look at Firefox, and VS.NET, and..."
Then I read this last comment and things became a little clearer. ( = You're differentiating between tabs and having actual little windows inside a larger parent window... but those windows can't escape the confines of the larger window. Yeah, from a usability viewpoint that really sucks -- just when the user was getting used to how windows behave along come these windows that the user can't close, move as they like, etc...
However, VS.NET *is* MDI... they just hide it with a pretty tab control. If you go the the Windows menu and say "Cascade" then you will be presented with good ol' MDI.
Thanks again!
@David. When REALbasic users talk about MDI, they mean the child-within-parent setup. So, as far as we are concerned Firefox and VS.NET *don't* use an MDI interface. It's confusing that MDI actually means a Multiple Document Interface, which of course is seen in thousands of apps.
@David -- I just popped open VS.NET (2005), and it's certainly not an MDI. A quick run of Spy++ showed that it's a regular window frame. Also, there was no cascade option under the Windows menu. Perhaps VS.NET 2003 was MDI, but I suspect it was a faked MDI (sort of like how our window editor is a faked MDI).
@Charlie -- you hit the nail on the head. The MDI I am referring to is the UI concept on Windows. Not the design concept of an app which hosts multiple "documents."
My bad!!!
I was confused with the meaning of MDI rather than the concept of multiple windows inside main parent window.
Now comes the more important question, how to implement tabbed window / multiple document interface in RB ? Esp. if these windows are not exacty the same class (maybe superclass ?)
FYI, if tabbed interfaces were coded *correctly* (like they are in BeOS, for instance), and had proper OS support, they'd could go on the taskbar in an intelligent manner. Really, tabbed interfaces should be a function of the Window Manager (ala BeOS) and not the application.
This is what bothers me about apps like Firefox, GAIM, and other apps that use tabbed windows... what they're doing is sending the message "your OS is so crappy at handling windows that I'm going to bypass its method and do it my own way." And the *really* sad part is that they're right: OS X, Windows, and Linux all suck at handling windows in many fundamental ways. One of those ways being the inability to keep multiple windows glommed together in a single tabbed-object. BeOS could do it in 1996; why hasn't anybody else implemented it?
The biggest problem with MDI as I see it is that it removes choice from the user. Say I want to layer a Word window, an Excel window, then another Word window to do some side-by-side comparison... with Office 95, that would be entirely impossible because the two Word documents (in an MDI) would be surrounded by this pointless grey blob window that covers up the Excel spreadsheet. It defeats the purpose of using windows in the first place!
MDI basically is saying, to the user, "our application is SO important that we think you'll want it maximized all the time." It's the window equivalent of all those apps that fart icons in your start menu, quickstart, desktop, systray: "We think our app is so important you'll want instant access to it from a dozen places." Well, news to developers: It's not.
I should mention that the beauty of the OS tracking tabs, and not individual apps, is that I can open a browser window, a Word window, and a email window (all related to the same project) and keep them all in a single set of tabs. With Firefox's tabs, you can't do that, nor can you with GAIM or any other tabbed application; it requires tabs being supported by the Window Manager.
Basically, I'm just lamenting that it's been a decade since BeOS, and OS makers still haven't adopted *any* of the innovations they introduced. It's shameful.
[...] 1) If there are more than 10-15 “controls” in any given view, then the UI needs to be redesigned. Now, what do I mean by “control?” I mean a logical set of functionality. So if you have a GroupBox surrounding a set of radio buttons, that’s one control. If you have a static text which describes an edit field, that’s one control. If you have too much “stuff” going on in any given view of your program, then your program is going to be very confusing to users. I’ve seen projects with 200+ controls on a single window — that’s unacceptable in just about any plausible scenario (aside from “I use this myself, and I’m the only one who uses it). Too much stuff = Bad UI. 2) If you have more than four radio buttons, it should probably be a popup menu. Radio buttons allow you to pick one option from a group of choices. That’s the same behavior you get out of a PopupMenu control. The difference is that the popup menu only takes up space for one control, and radio buttons take up multiple spaces, plus the groupbox space. 3) If you have a tab panel inside of another tab panel, you need to redesign your UI. There’s no good reason for a tab panel inside of a tab panel. If you point out published apps which do it, then great! You should write to them and complain. 4) If you have more than three different colors (excluding images and icons and things like syntax highlighting, hyperlinks, etc) in any given view, you should rethink your design. I’m talking about the UI where the window is a non-standard background color, and then each button on the window is also a non-standard UI color. Are those colors really needed? Because color usually detracts from a UI when used improperly. The more colors on the screen, the more confusing it is for your eyes to pick out any single important piece of the UI. Obviously, kids programs are excluded from this one. :-P 5) Any time there’s a standard control with a non-standard color (be it text or background color), or non-standard font (size, style or face), it’s time to really think hard about why there’s a deviation. In some cases, it’s perfectly acceptable. For instance, showing a user’s color choice in a listbox. Or showing a user’s font preference in a static text. Those sort of things are valid reasons. Having red text with a bold font style in a non-system font face at size 32 in a PushButton for just about any reason is invalid. ;-) Seriously — use system fonts with system colors whenever possible. If you want to draw attention to the control, there are other ways to do so. 6) If anything is flashing in the UI, it better be an EditField caret. 7) MDI is unacceptable. 8) When in doubt, refer to the OS interface guidelines and follow them. They’re put there for a reason and usually will show you the proper way to do things. 9) If you have more than 15-20 items in a menu, it’s time to redesign that menu. Similarly, if you have < 3-5 items in the menu, you may want to do the same thing. Too many menu items scares people into thinking something is overly complex. Hiding related menu items in sub menus can help (but don’t nest your submenus very deep!). Having too few items on a menu is a waste of a top-level menu item. That’s screen real estate that the user sees always, so use it wisely. 10) Speaking of menus, you should never, ever have items that come and go. Only enable and disable. It’s very confusing to users when menu items are sometimes there and sometimes not there. It’s much easier for them to understand “hey, I can’t use this right now, but it’s still there when I need it.” than it is for them to grok “hey, wait, I swore there was an item to do X here. Now where did that go?” You should setup your menu items when the app launches, and only set them up once. Once you have the menus set, then you can enable and disable as needed. Not certain if this rule applies to the Mac, where there’s only one menu bar. 11) Continuing with the menus — if you have an item that is always disabled, you’ve done something wrong. People will go nuts trying to figure out how to enable it. If it’s going to always be disabled, it should have been removed at app launch time. A good example of when people do this is for debugging purposes, or registering purposes. If the user’s already registered, then remove the item (at launch time) so they never see it. Don’t just have it always disabled there, taunting them. 12) Don’t mix up a PopupMenu and a ComboBox. They have separate uses. Use a ComboBox when it’s ok for a user to enter their own text in. Use a PopupMenu when it’s not ok. I see a lot of people use a ComboBox to display a list of items, and forget that the user can type in their own item. Bad mojo. 13) Similarly, and this is especially hard for Mac users, don’t confuse a PopupMenu and a ContextualMenu. A popup menu is there to show a list of data. It *does not* perform actions (aside from perhaps updating a StaticText somewhere, such as a description). Contextual menus are there for firing actions, popup menus are there for displaying lists of data. What’s more, on Windows, a popup menu has a very different visual look than a contextual menu (esp when compared to the Mac). 14) Contextual menus are your friend. I know that on the Mac, they are meant to be used sparingly. But on Windows and Linux, they’re expected. So if you have a handy thing to do that you feel people may want quick access to, you can stick it into a contextual menu for them. However, contextual menus are *contextual* and you would do well to remember that. This means that the context changes what’s in the menu. So if you right-click on a button, you should expect to get different results from right-clicking on an EditField. 15) Use system controls whenever possible. You may think you can design a button control that’s uber awesome and so much cooler than the system’s push button. But you’re probably wrong. Because that system push button can work with screen readers. It supports high contrast mode. It properly supports keyboard and mouse interaction. It can do the right thing with a pressure screen. It gets rendered with the user’s settings. And so on. There’s a lot of work that the OS vendor does for you with their controls, and it’s almost *always* better to let them do that work for you. So while your control may look prettier, it will probably also work worse. [...]
MDI may not be dead, but according to Microsoft it's being phased out.
The future is in multi-panel single-window designs, which are not only less confusing to the user but also work well across all platforms (see iMovie, iPhoto for Mac examples, or Adobe's new Lightroom for a cross-platform one, not to mention Thunderbird on all three OS families).
If you haven't been reading Jensen Harris' blog you're missing out on some other aspects of new single-window designs coming from Microsoft in Office 12:
http://blogs.msdn.com/jensenh/
@Myself -- good gods, that pingback is horrible!
@Richard -- Microsoft deprecated MDI and has been encouraging users to not use it since Windows 95 was released. Thanks for pointing out that blog link though. :-)