Modal window
From Wikipedia, the free encyclopedia
In user interface design, a modal window is a child window that requires the user 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. In the web (as the example image illustrates), they are often used to show images in detail.
Contents |
[edit] Relevance and usage
Modal windows are more common in the Microsoft Windows world, where modal windows frequently are an element of Multiple Document Interface applications, than in that of Mac OS, Unix-derivates, and the X Window System. In these OS's, many features that would be represented by modal windows in Windows are instead implemented as transient windows. 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.
[edit] Use Cases
Frequent uses of modal windows include:
- drawing attention to vital pieces of information. This use has been criticised as ineffective.[1][2][3]
- blocking the application flow until information required to continue is entered, as for example a password in a login process.
- 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) and for which better alternatives exist.[4]
[edit] Criticisms
A modal window blocks all other workflow in the program until the modal window is closed. 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 (see Mode error).
Sentiments against modal windows inspired some of the primary guidelines in early human-computer interface work. Microsoft's use of wizards for example, was seen as excessive in Windows 95[5].
Still, 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 advocate reducing the amount of user input at a given time.[citation needed] 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 practitioners oppose 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.[6] 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 alert dialogs are particular culprits of mode errors with potentially severe consequences. 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.[7]
Thus, the proposed correct solution to the problem would be to design every input element as a small, self-contained, task-oriented interaction (i.e. guided by the data dependencies required to complete a goal, not the interface states hardwired by the coder). For example, changing a visual aspect of the input element to reflect an invalid entry (such as applying a red border), or adding a character such as an asterisk next to the input element that needs to be corrected. This way, presenting several simultaneous input elements would be a benefit to the user, since they could switch easily from one to another following their flow of consciousness instead of being coerced into a predefined programmed path.
[edit] References
- ^ 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
- ^ Aza Raskin, A List Apart: Never Use a Warning When you Mean Undo
- ^ David A. Karp, HELP WITH WINDOWS 98
- ^ Cooper, Alan (March 17, 2003). About Face 2.0: The Essentials of Interaction Design. Wiley. ISBN 0764526413.
- ^ Raskin, Jef (2000). The Humane Interface. Addison Wesley. ISBN 0201379376.
[edit] Examples
- Modal Window in Joomla 1.5
- Lightview - by Nick Stakenburg
- ThickBox - modal windows JavaScript, built on jQuery
- TinyBox - another modal windows JavaScript, built on Prototype
- subModal DHTML Modal Dialog
- nyroModal - jQuery plugin highly customisable
- Control.Modal by Live Pipe
- MOOdalBox - a modal box built on mootools
- Lightbox JS by Lokesh Dhakar
- GreyBox by Amir Salihefendic
- getRealPopup by John Norton
- Modal Window Examples
[edit] See also
|
|||||||||||||||||||||||
