In user interface design, a modal window is a child window that requires users to interact with it before they can return to operating the parent application, thus preventing the workflow on the application main window. Modal windows are often called heavy windows or modal dialogs because the window is often used to display a dialog box.
Modal windows are commonly used in GUI systems to command user awareness and to display emergency states, although they have been argued to be ineffective for that use. Modal windows are prone to produce mode errors.
On the Web, they are often used to show images in detail.
Relevance and usage 
Use cases 
Frequent uses of modal windows include:
- Drawing attention to vital pieces of information. This use has been criticised as ineffective because users are bombarded with too many dialog boxes, and habituate to simply clicking "Close", "Cancel", or "OK" without reading or understanding the message.
- Blocking the application flow until information required to continue is entered, as for example a password in a login process. Another example are file dialogs to open and save files in an application.
- Collecting application configuration options in a centralized dialog. In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made.
- Warning that the effects of the current action are not reversible. This is a frequent interaction pattern for modal dialogs, but it is also criticised by usability experts as being ineffective for its intended use (protection against errors in destructive actions) due to habituation. Actually making the action reversible (providing an "undo" option) is recommended instead.
Modal sheets in Mac OS X 
Many features that would typically be represented by modal windows are implemented as modal transient panels called Sheets on Mac OS X. Transient windows behave similarly to modal windows – they are always on top of the parent window and are not shown in the window list, but they do not disable the use of other windows in the application. Sheets slide out of the window's title bar, and usually need to be dismissed before the window can continue to be used, but the rest of the application will stay usable. Thus they create a mode inside the window containing them, but are modeless with respect to the rest of the application.
A modal window blocks all other workflow in the top-level program until the modal window is closed, as opposed to modeless dialogs that allow users to operate with other windows. Modal windows are intended to grab the user's full attention. Users may not recognize that a modal window requires their attention, leading to confusion about the main window being non-responsive, or causing loss of the user's data input intended for the main window (see Mode error).
However, many interface designers have recently taken steps to make modal windows more obvious and user friendly by darkening the background behind the window or allowing any mouse click outside of the modal window to force the window to close – a design called a Lightbox – thus alleviating those problems. Jakob Nielsen states as an advantage of modal dialogs that it improves user awareness: "When something does need fixing, it's better to make sure that the user knows about it". For this goal, the lightbox design provides strong visual contrast of the dialog over the rest of the visuals. The lightbox technique is now a common tool in website design.
Control of interaction flow 
Modal windows are an integral part of common GUI toolkits and are frequently used when designing user workflow. Believing that too many active modeless dialogs can lead users into confusion, proponents of modal windows[who?] advocate reducing the amount of user input at a given time. This, they argue, can reduce user confusion, while minimizing the likelihood of an error as a result of having too many modeless windows open concurrently.
Usability analyst Alan Cooper opposes these claims arguing that restriction of user actions for the sake of usability is an error, since this leads to user frustration for no benefit. User input is necessarily entered at one place at a time, as it requires conscious attention anyway. Users can handle complex amounts of information, given that it's presented in a well-structured and logical design, by performing a preliminary general scanning and then centering their attention in the tool required to complete a goal; complex goals will often require switching attention from one point to another.
Unexpected interruptions 
Unexpected alert dialogs are particular culprits of mode errors with potentially severe consequences. Usability practitioners prescribe that dangerous actions should be undoable wherever possible; an alert box that appears unexpectedly or which is dismissed by habituation will not protect from the dangerous action. A modeless infobar is increasingly seen as preferable to a dialog box because it does not interrupt the user's activities, but rather allows the user to read extra information in their own time.
One proposed approach is to design every input element as a self-contained, task-oriented interaction, guided by its own specific requirements rather than by the global state of the entire application. For example, required elements might be preceded with an asterisk, elements with invalid data might acquire a red border, and so on. With this approach, users actually benefit from seeing many input elements at once — they can enter data in a way that makes sense to them, instead of having all the other unrelated elements blocked until a predefined data-entry sequence is completed.
Design recommendations 
Modal dialogs are part of a task flow, and recommendations are given to place them where the focus is in that flow. For example, the window can be placed near the GUI control that triggers its activation.
Using a semi-transparent dark background can obscure the information in the main window, so it's advised to be used only when that information would be distracting.
Design should follow common practices in the current platform. Microsoft Windows use standard controls for modal window dialogs with affirmative action buttons at the lower right of the panel. Mac OS X uses modal sheets with affirmative action buttons being the left-most command.
See also 
- Aza Raskin, A List Apart: Never Use a Warning When you Mean Undo
- Quince UX patterns explorer. "Modal Panel".
- Joel Spolsky, User Interface Design for Programmers: Designing for People Who Have Better Things To Do With Their Lives
- Raymond Chen, The Old New Thing: The default answer to every dialog box is "Cancel"
- Jeff Atwood, Coding Horror: Teaching Users to Read
- "How to Use Modality in Dialogs". Oracle Corporation.
- Infragistics.com. "Modal Panel".
- Jakob Nielsen, Alertbox. "10 Best Application UIs".
- Cooper, Alan (March 17, 2003). About Face 2.0: The Essentials of Interaction Design. Wiley. ISBN 0-7645-2641-3.
- Raskin, Jef (2000). The Humane Interface. Addison Wesley. ISBN 0-201-37937-6.
- Infragistics.com. "Modal Panel - Implementation".