View source for Modal window

{{Short description|Subordinate user interface element}}
{{distinguish|Dialog box}}
In [[user interface]] design, a '''modal window''', or '''modal''' for short,<ref>{{Cite web |last=Segun |first=Daniel |date=2022-09-07 |title=Are Modals In Web Design A UX Disaster? |url=https://webdesignerdepot.com/are-modals-in-web-design-a-ux-disaster/ |access-date=2025-09-26 |language=en-US}}</ref><ref>{{Cite web |last=Coyier |first=Chris |date=2016-07-18 |title=Considerations for Styling a Modal |url=https://css-tricks.com/considerations-styling-modal/ |access-date=2025-09-26 |website=CSS-Tricks |language=en}}</ref> is a [[Graphical control element (software)|graphical control element]] subordinate to an application's [[main window]].

A modal window creates a [[Mode (user interface)|mode]] that disables user interaction with the main window but keeps it visible, with the modal window as a [[Window (computing)#Properties|child window]] in front of it. Users ''must'' interact with the modal window before they can return to the [[Tree (data structure)#Terminology|parent]] window. This avoids interrupting the [[workflow]] on the main window. Modal windows are sometimes called '''heavy windows''' or '''modal dialogs''' because they often display a [[dialog box]].

User interfaces typically use modal windows to command user awareness and to display emergency states, though [[interaction designer]]s argue they are ineffective for that use.<ref name="undo"/> Modal windows are prone to [[mode error]]s.<ref name="undo">{{Cite web|title = Never Use a Warning When you Mean Undo|url = http://alistapart.com/article/neveruseawarning|website = alistapart.com|access-date = 2015-10-09}}</ref><ref>{{Cite book|title = The Humane Interface|last = Raskin|first = Jef|publisher = Addison Wesley|year = 2000|isbn = 0-201-37937-6|location = United States|url = https://archive.org/details/humaneinterfacen00rask}}</ref><ref>{{Cite web|title = Nitpicker / The Humane Interface|url = http://nitpicker.pbworks.com/w/page/12451253/The%2520Humane%2520Interface|website = nitpicker.pbworks.com|access-date = 2015-10-09|at = Rule 1a.}}</ref>

On the [[World Wide Web|Web]], they often show images in detail, such as those implemented by [[Lightbox (JavaScript)|Lightbox]] library, or are used for [[Hover ad|hover ads]].<ref>{{Cite web|title=Modal Panel|author=Quince UX patterns explorer|url=http://quince.infragistics.com/Patterns/Modal%20Panel.html|url-status=dead|archive-url=https://web.archive.org/web/20100227095647/http://quince.infragistics.com/Patterns/Modal%20Panel.html|archive-date=2010-02-27}} The popular Lightbox JavaScript library uses a modal panel approach for showing the images</ref><ref name="useit"/>

The opposite of modal is '''[[modeless]]'''. Modeless windows don't block the main window, so the user can switch their [[user focus|focus]] between them, treating them as [[palette window]]s.

==Relevance and use==

===Use cases===

Frequent uses of modal windows include:
* Drawing attention to vital pieces of information. This use has been criticized 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.<ref>[[Joel Spolsky]], User Interface Design for Programmers: [http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html Designing for People Who Have Better Things To Do With Their Lives]</ref><ref>[[Raymond Chen]], The Old New Thing: [https://devblogs.microsoft.com/oldnewthing/20030901-00/?p=42723 The default answer to every dialog box is "Cancel"]</ref><ref>Jeff Atwood, Coding Horror: [http://www.codinghorror.com/blog/archives/000114.html Teaching Users to Read]</ref>
* Blocking the application flow until information required to continue is entered, as for example a [[password]] in a [[Logging (computer security)|login]] process. Another example are [[file dialog]]s 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 design pattern|interaction pattern]] for modal dialogs, but some usability experts criticize it as ineffective for its intended use (protection against errors in destructive actions) due to [[habituation]]. They recommend making the action reversible (providing an "undo" option) instead.<ref name="undo"/>

===Modal sheets in Mac OS X===
{{redirect-distinguish|Sheet (computing)|spreadsheet}}
Many features that would typically be represented by modal windows are implemented as modal [[Transient screen|transient]] panels called "Sheets"<ref>{{cite web |title=Sheets - Presentation - Components - Human Interface Guidelines - Design - Apple Developer |url=https://developer.apple.com/design/human-interface-guidelines/components/presentation/sheets/ |website=Apple Developer |access-date=7 September 2022}}</ref> on Mac OS X. Transient windows behave similarly to modal windows{{spaced ndash}}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 must be dismissed before the user can continue to work in the window, but the rest of the application stays usable. Thus they create a mode inside the window that contains them, but are modeless with respect to the rest of the application.

==Control of interaction flow==
Modal windows are common in GUI toolkits for guiding user workflow. [[Alan Cooper (software designer)|Alan Cooper]] contends that the importance of requiring the user to attend to important issues justifies restricting the user's freedom and that the alternative would increase user frustration.<ref>{{cite book 
|last=Cooper 
|first=Alan 
|title=About Face 2.0: The Essentials of Interaction Design 
|publisher=Wiley 
|date=March 17, 2003 
|isbn=0-7645-2641-3 
|url=https://archive.org/details/aboutface20essen0000coop 
}}</ref>

=== Unexpected interruptions ===

Unexpected [[Alert dialog box|alert dialogs]] are particular culprits of [[mode error]]s<ref name="undo"/> with potentially severe consequences. Usability practitioners prescribe that dangerous actions should be undoable wherever possible; an alert box that appears unexpectedly or is dismissed by [[habituation]] doesn't protect from the dangerous action.<ref>{{cite book |last=Raskin |first=Jef |title=The Humane Interface |publisher=Addison Wesley |date=2000 |isbn=0-201-37937-6 |url=https://archive.org/details/humaneinterfacen00rask }}</ref> 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 analysis|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.

=== Problems ===
{{See also|Mode_(computer_interface)#Assessment|l1=Assessment of modes in computer interfaces}}

A modal window blocks all other [[workflows]] in the top-level program until the modal window is closed, as opposed to [[modeless]] dialogs that allow users to operate with other windows.<ref name="java">{{cite web|url=http://download.oracle.com/javase/tutorial/uiswing/misc/modality.html|title=How to Use Modality in Dialogs|publisher=[[Oracle Corporation]]}}</ref> Modal windows are intended to grab the user's full attention.<ref>{{Cite web |author= |title=Modal Panel |url=http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Problem |url-status=dead |archive-url=https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Problem |archive-date=2013-05-06 |website=quince.infragistics.com}}</ref> 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]]). In severe cases, the modal window appears behind another window controlled by the same program, potentially rendering the entire program unresponsive until the modal window can be located manually.

However, many interface designers have recently taken steps to make modal windows more obvious by darkening the background behind the window or allowing any mouse click outside of the modal window to force the modal window to close – a design called a [[Lightbox (JavaScript)|Lightbox]]<ref name="useit">{{Cite web|url=http://www.useit.com/alertbox/application-design.html|title=10 Best Application UIs|author=Jakob Nielsen, Alertbox}}</ref> – 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.

Modal windows are commonly implemented in ways that block the possibility to move, minimize, iconify, or push that window back, and they grab input focus, which often prevents use of a system's [[cut, copy, and paste]] facilities. This can interfere with the use of their parent applications by blocking access to other windows and data within the same application, particularly in cases where the modal window is requiring the user to input information only available in one of the windows it's covering.

For users using virtual work areas larger than their actual screens, modal windows can cause further undesirable behavior, including creating the modal on a portion of the virtual screen not currently on the display, or abruptly switching the display from what the user was working on to an entirely different section.

Modal windows tend to create an abrupt diversion of text input, especially typed input intended for other programs, into themselves. Further, modals usually interpret actuation of the [[enter key]] (or in rare cases the presence of a [[newline]] in pasted input) as a cue to accept the input and process it—or, in rare cases, may intercept a mouse click intended for a different application that has suddenly been covered. Such interception, called [[focus stealing]] (or stealing focus) can compromise privacy and security practices, as well as capture inappropriate, out-of-context input that can cause undefined, arbitrary results in the program that generated the modal window.

Depending on the specifics of implementation, modal windows can violate the [[principle of least surprise]].

=== Recommendations ===
{{See also|Mode (user interface)#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 could be placed near the [[Graphical control element (software)|graphical control element]] that triggers its activation.<ref name="Implementation">{{Cite web |author= |title=Modal Panel - Implementation |url=http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Implementation |url-status=dead |archive-url=https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Implementation |archive-date=2013-05-06 |website=quince.infragistics.com}}</ref>

Using a semi-transparent dark background can obscure information in the main window, so it is best used only when that information would be distracting. A semi-transparent background can be made less intrusive by having the whole background area function as a close button: this is standard on most mobile operating systems, avoids making the user feel trapped, and makes modal windows feel less like malicious pop-ups.

Design should follow common practices in the platform the program is running on. [[Microsoft Windows]] uses standard controls for modal [[window dialog]]s, with affirmative action buttons at the lower right of the panel. [[Mac OS X]] uses [[modal sheet]]s with affirmative action buttons being the right-most command.<ref>{{cite web|url=https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowDialogs.html#//apple_ref/doc/uid/20000957-CH43-SW1|title=Themes - macOS - macOS - Human Interface Guidelines - Apple Developer|first=Apple|last=Inc.|website=developer.apple.com|access-date=18 September 2018}}</ref>

==See also==
*[[Application posture]]
*[[Popover (GUI)]]

==References==
{{Reflist|30em}}

{{Graphical control elements}}

{{DEFAULTSORT:Modal Window}}
[[Category:Graphical user interface elements]]