Editing Multiple-document interface (section)

==Comparison with single-document interface==
In the [[usability]] community, there has been much debate about whether the multiple-document or single-document interface is preferable. Software companies have used both interfaces with mixed responses. For example, [[Microsoft]] changed its [[Microsoft Office|Office]] applications from SDI to MDI mode and then back to SDI, although the degree of implementation varies from one component to another. SDI can be more useful in cases where users switch more often between separate applications than among the windows of one application.

MDI can be confusing if it has a lack of information about the currently opened windows. In MDI applications, the application developer must provide a way to switch between documents or view a list of open windows, and the user might have to use an application-specific menu ("window list" or something similar) to switch between open documents. This is different from SDI applications where the window manager's [[task bar]] or [[task manager]] displays the currently opened windows. In recent years it has become increasingly common for MDI applications to use "tabs" to display the currently opened windows. An interface in which tabs are used to manage open documents is referred to as a "[[tabbed document interface]]" (TDI). Another option is "tiled" [[Paned window (computing)|panes]] or windows, which make it easier to prevent content from overlapping.

Some applications allow the user to switch between these modes at their choosing, depending on personal preference or the task at hand.

Nearly all [[graphical user interface]] toolkits to date provide at least one solution for designing MDIs. A notable exception was [[Cocoa (API)|Apple's Cocoa API]] until the advent of tabbed window groups in [[MacOS High Sierra]]. The [[Java (programming language)|Java]] GUI toolkit, [[Swing (Java)|Swing]], for instance, provides the class {{Javadoc:SE|package=javax.swing|javax/swing|JDesktopPane|module=java.desktop}} which serves as a container for individual frames (class {{Javadoc:SE|package=javax.swing|javax/swing|JInternalFrame|module=java.desktop}}). [[GTK]] lacks any standardized support for MDI.

===Advantages===
* With multiple-document interfaces (and also [[tabbed document interface]]s), a single menu bar and/or [[toolbar]] is shared between all child windows, reducing clutter and increasing efficient use of screen space. This argument is less relevant on an operating system which uses a common menu bar.
* An application's child windows can be hidden/shown/minimized/maximized as a whole.
* Features such as "Tile" and "Cascade" can be implemented for the child windows.
* Authors of cross-platform applications can provide their users with consistent application behaviour between platforms.
* If the windowing environment and OS lack good window management, the application author can implement it themselves.
* Modularity: An advanced window manager can be upgraded independently of the applications.

===Disadvantages===
* Without an MDI frame window, floating toolbars from one application can clutter the workspace of other applications, potentially confusing users with the jumble of interfaces.
* Can be tricky to implement on desktops using multiple monitors as the parent window may need to span two or more monitors, hiding sections.
* [[Virtual desktop]]s cannot be spanned by children of the MDI. However, in some cases, this is solvable by initiating another parent window; this is the case in [[Opera (web browser)|Opera]] and [[Google Chrome|Chrome]], for example, which allows tabs/child windows to be dragged outside of the parent window to start their own parent window. In other cases, each child window is also a parent window, forming a new, "virtual" MDI [https://web.archive.org/web/20110818050252/http://hypotext.webs.com/web1.htm].
* MDI can make it more difficult to work with several applications at once, by restricting the ways in which windows from multiple applications can be arranged together without obscuring each other.
* The shared menu might change, which may cause confusion to some users. <!-- But if this is a common problem, why is it not a problem on OS X, where the menu bar is shared by ''all'' applications? Can someone actually cite studies on this subject? ( I agree to this comment --~~~~ ) -->
* MDI child windows behave differently from those in [[single-document interface]] applications, requiring users to learn two subtly different windowing concepts. Similarly, the MDI parent window behaves like the desktop in many respects, but has enough differences to confuse some users.
* Deeply nested, branching hierarchies of child windows can be confusing.
* Many window managers have built-in support for manipulating groups of separate windows, which is typically more flexible than MDI in that windows can be grouped and ungrouped arbitrarily. A typical policy is to group automatically windows that belong to the same application. This arguably makes MDI redundant by providing a solution to the same problem.
* Controls and hotkeys learned for the MDI application may not apply to others, whereas with an advanced Window Manager, more behavior and user preference settings are shared across client applications on the same system