Even though MDI is considered harmful, several applications (even MS Office, Adobe apps) still use it either in its pure form or some as a hybrid with a tabbed/IDE-like interface.
Is an MDI interface still appropriate for some applications?
I'm thinking of an application where one typically works with several documents at one time, and often wants to have multiple documents side to view or copy/paste between them.
An example would be Origin, where one has multiple worksheet and graph windows in a project; a tabbed or IDE-like interface would be much more inconvenient with a lot of switching back and forth.
On the mac, it's natural and convenient for an application to have multiple top-level windows to solve this, what is the preferred way in Windows if one doesn't use MDI?
Even though MDI is considered harmful, several applications (even MS Office, Adobe apps) still use it either in its pure form or some as a hybrid with a tabbed/IDE-like interface.
MDI child forms are an essential element of Multiple-Document Interface (MDI) applications, as these forms are the center of user interaction. In the following procedure, you'll use Visual Studio to create an MDI child form that displays a RichTextBox control, similar to most word-processing applications.
Multiple-document interface (MDI) applications enable you to display multiple documents at the same time, with each document displayed in its own window. MDI applications often have a Window menu item with submenus for switching between windows or documents. Note.
The disadvantages of MDI are the following:
It generally requires the user to learn and understand a more complicate set of window relations.
Many simple actions can require a two-step process. For example, bringing a desired window to the foreground can require that the user first brings the container window forward then bring the right primary window in the container window forward. Resizing or maximizing a window can mean first adjusting the container window then the primary window within.
If multiple container windows are open, the user can forget which one has the desired primary window, requiring a tedious search.
Users are easily confused by the dual ways to maximize, iconify, layer, and close a window. For example they may close the entire app rather than a window within the container window. Or they may “lose” a window because they iconified it within the container window without realizing it.
The user is limited in the sizes and positions his or her windows can assume. Suppose I want to look simultaneously at 3 windows of one app and 1 from another app. With SDI, I can have each window take a quadrant of the screen, but I can’t do that with MDI. What if I want one window in the MDI to be large and the other small? I have to make the container window large to accommodate the large window (where it occludes the windows of other apps), but that wastes space when looking at the child.
Note that all of these disadvantages apply to tabbed document interfaces (TDI) too, with tabbed interfaces having the additional disadvantage that the user can’t look at two documents in the same container window side by side. Tabs also add clutter and consume real estate in your windows. However, overall TDI tend to be less problematic than MDI, so they might be preferred for special cases (read on)
In summary, it hard to think of any situation to use MDI. It’s no better than an SDI while adding more complexity and navigation overhead, and working poorly with the windows of other apps.
There’s no reason an app can’t have multiple top-level SDI windows. Even with an app like Origin, I don’t see a problem with a project being spread across multiple SDI windows as long as the project is well identified in each window. SDI also allows different kinds of windows (e.g., graph vs worksheet) to have different menus and toolbars, rather than hiding or disabling items depending on the active window (the former is confusing, and the latter wastes space).
SDI gives your users the more flexibility over either MDI or TDI. Users can overlap or maximize the windows, and use the taskbar/dock as a de facto tab interface. Users can alternatively resize and reposition the windows so they can look at multiple at once. Each window can be sized independently to optimize screen space. Whatever advantages an MDI or TDI may have, you may be able augment SDI to have those advantages too (e.g., provide a thumbnailed menu that makes switching among windows faster than using the taskbar and comparable to selecting tabs, or provide a control that iconifies all windows of an app with one click).
Unless you have compelling reasons to use a TDI, go SDI to allow this flexibility. Compelling reasons include some subset of the following:
Each tab is used for unrelated high-order tasks and user will not be switching among tabs frequently or comparing information across tabs.
You’re working with very low-end users who are ignorant of or confused by the taskbar/dock and multiple windows, and don’t know how to resize windows (it seems compelling tab imagery works better than the taskbar for such users).
You anticipate there’re typically be a large set of tabs (e.g., 4 or more) and you can control their display in a manner more effectively for the task than the OS can if they were SDI windows on the taskbar/dock (e.g., with regard to order and labeling).
With SDI, you’re having problems with users confusing the toolbars or palettes of inactive windows with active windows.
Tabs are fixed in number and permanently open (e.g., when each tab is a different component of the same data object). The user is not saddled with trying to distinguish between closing a tab and closing the entire window; figuring out the window to navigate to is not an issue because all windows have the same tabs.
There is really only one way to properly arrange the data for task, with no variation among users or what they actually use the app for. You might as well set it up for the user with a combination of tabs and master-detail panes and rather than relying on the user to arrange and size SDI windows right.
In summary, given your users’ abilities, app complexity, and task structure, if your app can manage the content display better than the user/OS, use TDI, otherwise use SDI.
Note that the examples you used (MS Office and Adobe applications) are big programs and have lots of features. Users will be dealing with that program, and only that program for much of the program's lifetime.
Newer versions of MS Office (2007) and Adobe Photoshop (CS4) use multiple windows and tabs, respectively.
Note that with Windows 7, MDI's will probably lose popularity even more because of the extra power of tabs given by Microsoft's API's (although you needn't strictly use tabs -- MDI windows could work, but would be more confusing for the user than usual).
The old-style MDI (where to switch between documents, you had to go through the Windows menu) was annoying. The newer MDI (like tabs in Opera and Mozilla) make switching between documents very easy and seem to have been accepted well. They also don't clutter your taskbar as happens if you had more than one document open in something without MDI.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With