In graphical user interfaces, a single document interface or SDI is a method of organizing graphical user interface applications into individual

windows that the operating system's window manager handles separately. Each window contains its own menu or tool bar. This contrasts with a multiple document interface, in which a single parent window is used to contain multiple nested child windows, with only the parent window having a menu or tool bar. The Single Document Interface (SDI) approach defines a single primary form in the application, with secondary forms used only for supplemental tasks. Notepad is an example of an SDI application. If you are building a text editor application, for example, you can define one single primary form that is the text editor. Your secondary forms provide for supplemental tasks such as selecting fonts or colors. These secondary forms are most often modal, allowing the user to make a selection and then immediately dismiss the form before continuing. Other types of applications that benefit from an SDI approach include point of sale applications and management console applications. Having one primary form in your application reduces confusion and distractions for the user. SDI is great for situations where you want the user to focus on one key form. Controller Form The controller form approach defines a primary form in the application and all the other forms are accessed from this form. This is similar to the SDI approach but allows for extended functionality and modeless secondary forms. 4. BUILDING THE USER INTERFACE LAYER If you are building a simple management application, such as Customer Management, you may have a grid form that lists all your customers. This is the primary form in the application. Double-clicking on one of the entries in the grid form displays the customer information details for review or edit. Right-clicking a grid entry provides a menu to access the customers credit information, purchase history, and so on. So the primary form controls access to all the other forms in the application. This approach works best in single purpose applications that dont have a large number of forms. The downside of this approach is that it is easy to lose track of all the forms of the application because they are not constrained by a single workspace or container. Often in single document interfaces, each window is represented as an individual entry in the operating system's task bar or manager. Applications which allow the editing of more than one document at a time, e.g. word processors, may therefore give the user the impression that more than one instance of an application is open. Some task managers summarize windows of the same application. For example, Mac OS X uses a feature called Expos which allows the user to temporarily see all windows belonging to a particular application. Multiple Document Interface In graphical user interfaces, a multiple document interface or MDI is one whose windows reside under a single parent window. Such systems often allow child windows to embed other windows inside them as well, creating complex nested hierarchies. This contrasts with single document interfaces (SDI) where all windows are independent of each other.

The Multiple Document Interface (MDI) approach defines a container within which all the other features of the application are accessed. The container normally includes a menu, toolbar(s), and a status bar. Options on the menu and toolbar provide access to all the other forms that are displayed as independent windows within the client area of the MDI form. Microsoft Excel is an example of an MDI application. You can easily work with multiple spreadsheets within the Excel workspace. MDI allows the user to view many different types of information as separate forms within the MDI container. The user can lay out the forms, or use the MDI options to arrange the forms in a cascading fashion or tiled vertically or horizontally. And minimizing the MDI container minimizes all the forms within the container, making it easy to keep track of all the forms. NOTE: Visual Studio itself can be set to use the MDI approach (Tools | Options | Environment | General | Window Layout). When you set the Window Layout to Multiple documents the editors and designers each appear as separate forms within the Visual Studio container. A built-in MDI Parent Form template is provided in Visual Studio to assist you with building an MDI user interface. It includes the standard set of menu and toolbar options to save you the time of defining them all manually. Use the MDI approach when you have different types of information to display and you want the user to be able to view multiple types simultaneously. MDI is great for multifeatured business applications, such as Purchase Tracker. 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 Office applications from SDI to MDI mode and then back to SDI, although the degree of implementation varies from one component to another. Generally, SDI is seen[by whom?] as more useful in cases where users work with more than one application. The disadvantage of MDI usually cited is its 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 in contrast to SDI applications, where the window manager's task bar or task manager displays the currently opened windows. However, in recent years it has become increasingly common for MDI applications to use "tabs" to display the currently opened windows, which has made this criticism somewhat obsolete. An interface in which tabs are used to manage open documents is referred to[by whom?] as a "tabbed document interface" (TDI). Another option is "tiled" 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, with an exception being Apple's Cocoa API. The Java GUI toolkit, Swing, for instance, provides the class javax.swing.JDesktopPane which serves as a container for individual frames (class javax.swing.JInternalFrame). GTK+ lacks any standardized support for MDI. Advantages With multiple document interfaces (and also tabbed document interfaces), 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. 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.

Disadvantages

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 desktops cannot be spanned by children of the MDI. However, in some cases, this is solveable by initiating another parent window; this is the case in Opera and 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 [1]. 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. 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 Modularity: An advanced window manager can be upgraded independently of the applications

Application examples

Internet Explorer 6: a typical SDI application Visual Studio 6 development environment: a typical modern MDI Visual Studio .NET: MDI or TDI with "Window" menu, but not both Opera: Combination of MDI and TDI (a true MDI interface with a tab bar for quick access). Chrome: Combination of MDI and TDI. Paint.NET: Thumbnail-based, TDI Firefox: TDI by default, can be SDI GIMP: SDI with floating windows (MDI is available as an option called "Single-Window Mode" since version 2.8[2]). GIMPshop: A fork of GIMP aiming to be more like Adobe Photoshop. The Windows version has limited MDI.[3] Adobe Photoshop: MDI under MS Windows. In newer versions, toolbars can move outside the frame window. Child windows can be outside the frame unless they are minimized or maximized. Adobe Acrobat: MDI until version 7.0 (Windows-only); SDI default in 8.0 (configurable to MDI); SDI only in 9.0. Microsoft Excel 2003: SDI if you start new instances of the application, but MDI if you click the "File New" menu (but child windows optionally appear on the OS taskbar) Microsoft Word 2003: MDI until Microsoft Office 97. After 2000, Word has a Multiple Top-Level Windows Interface, thus exposing to shell individual SDI instances, while the operating system recognizes it as a single instance of an MDI application. In Word 2000, this was the only interface available, but 2002 and later offer MDI as an option.

Microsoft Foundation Classes (which Office is loosely based on) supports this metaphor since version 7.0, as a new feature in Visual Studio 2002. UltraEdit: Combination of MDI and TDI (a true MDI interface with a tab bar for quick access). VEDIT: Combination of MDI and TDI (a true MDI interface with a tab bar for quick access). Special "Full size" windows act like maximized windows, but allow smaller overlapping windows to be used at the same time. Multiple instances of Vedit can be started, which allows it to be used like an SDI application. Notepad++, PSPad, TextMate and many other text editors: TDI EmEditor: Options for either SDI or MDI. Macromedia Studio for Windows: a hybrid interface; TDI unless document windows are un-maximized. (They are maximized by default.) Corel Wordperfect: MDI. A user can open multiple instances of WP with a single document in each, if they have multiple versions of WordPerfect installed on their computer. Recent versions maintain a list of open documents for a given window on the status bar at the bottom of the window, providing a variant of the TDI. Zeus for Windows: Combination of MDI and TDI (a true MDI interface with a tab bar for quick access). mIRC: MDI by default, can also work on SDI mode