Talk:Modal window

Hi.

I noticed that there are 2 occurrences of the same typo/error. You typed "modeless" instead of "modaless" - the opposite programming design for GUI. It is in the last paragraph of the document.

I would appreciate if you fix it.

10x.

Modeless is the standard term. Alksub 09:11, 5 November 2006 (UTC)

Merge Article

The modality of a window, whether it forces interaction by disabling other interaction, is one attribute of a window. This is similar to whether a window is full screen or contains a title bar. This attribute does not make a window an inherently different graphical control element and any graphical control element could have modality. A drop down could similarly disable all other functionality until a choice is selected. There wouldn't be an article for 'modal down down' or 'full screen window'. Going forward, should this article be merged with window, popover, or mode? Nnivi (talk) 14:41, 31 January 2019 (UTC)

"To avoid interrupting main window's workflow?"

I though a modal window indeed interrupt main windows workflow and wait for user response (maybe some times, like the 'Quit window: Save - Delete - Cancel" window. — Preceding unsigned comment added by 181.226.253.162 (talk) 00:57, 11 November 2017 (UTC)

Modaless vs. Modeless

As a programmer, I have always known this term is "modaless" as opposed to "modal". You can check anywhere in the printed books as well as known sites such as Codeguru, etc. It is definitely Modaless. If you don't agree, I would suggest that at least it will be added between parentheses. Thanks.

Both words come from the Human-Computer Interaction field, where "modal" and "modeless" are words derived from the root word "mode". Thus deriving "modaless" from "modal" is an error, though it's easy to see why programmers (who only see the term "modal" in the context of modal windows) could commit that error. I have created a redirection from Modaless to Modeless to facilitate finding it. Diego 19:40, 14 November 2006 (UTC)

(And if YOU don't agree, just ask Google ) :-) Diego 19:45, 14 November 2006 (UTC)

Thanks for the clarification. I'll keep that in mind.

NPOV

Clearly this entire article was written by an anti-modal activist, for the sole purpose of demonstrating the overuse and inadequacy of modal windows. --64.149.36.43 (talk) 21:28, 16 April 2008 (UTC)

Could you explain which parts of the article are opinnions that have been expressed as facts, and how could we write them in a NPOV way? Diego (talk) 15:23, 24 June 2008 (UTC)

While I disagree that the sole purpose of this article is to criticize use of modal windows, the article could possibly be improved by expanding the section on legitimate uses, e.g. open or save file, requiring password of certain complexity, etc.
Additionally, the 4th reference citing alistapart.com is (I humbly ask you to excuse my language) POS. robust undo's? undo's in almost every place? A much better approach is to use meaningful labels like "overwrite" and "discard changes" instead of ubiquitous "OK" and "Cancel." It requires the users to make a conscious decision instead of a mechanical one, at the same time requires same amount physical effort as current widespread system.
sorry for the rant. also I went a little off-topic but I could not avoid criticizing the aforementioned reference. 72.66.27.118 (talk) 07:27, 18 July 2008 (UTC)

It's not a POV to assert that in current practice, modal windows is discouraged by the interaction design community. About the bias in the coverage, you'd need to find sources that support and explain what is a 'legitimate' usage.

What you call a POS is actually backed by scientific research by the senior Jef Raskin (see The Humane Interface). He found during his career in Human-Computer Interaction that Undo works so much better than desctructive operations, even if they are clearly labeled as such. The key of what he found is that people will make a mechanical decision, good mesage or not; it's called habituation. Having an Undo provides for exploring the application through what-if scenarios. The user doesn't know how the application works, so instead of keep wondering "is this overwrite what I really want to do?" (hint - the user has no way to tell in advance without reading the source code), she could just do the operation and revert it back if it's not what she needs.

(And as for forcing the user to "think about the message", just read this reference provided in the article) ;-) Diego (talk) 08:22, 18 July 2008 (UTC)

I've seen a usability designer explaining once how a user was bitten in the ass by MS Word with the very "discard changes" text. The victim spent 8-10 hours working on an important document, almost non-stop. Without saving (we can assume he was a novice user, at least before this story happened). With the document almost finished, he then went away for a while, and upon returning, made a few more edits. When he completed the work, closed the application, and then was asked: "The document has changed - do you want to save your changes?". Thinking of it, and deciding that the last few edits were not good and the document was better without them, pressed "Discard". You can guess the hilarity when trying to find were the one-day work was gone.

The moral of this story is, people think different than computers. To the user, all the work put into the computer is something that is already done (this is how it works in the real world, with pen and paper, after all). For the application, everything is temporary unless you trigger a separate action to make it persistent - save to disk. In the user's mind, the whole document was "completed", and the ambiguous warning about "changes" did apply only to the few last edits. Not so for the machine. This kind of model mismatch is far too common between people and computers, and is the more reason to provide safety mechanisms to protect people's time investment when something doesn't go as predicted. Diego (talk) 09:10, 18 July 2008 (UTC)

Are there still doubts about the current neutrality status? If not, I will remove the NPOV tag. Diego (talk) 10:57, 23 July 2008 (UTC)

Still reads as very non-neutral, which is why I was motivated to check this talk page. "Critizisms" is about half of the article, and "Modal sheets" contains implied criticism as well, and "Relevance and usage" contains rather dubious claims. The obvious uses such as save dialogs are not even mentioned. "Drawing attention to vital pieces of information" is not explained, no examples given, but instead only information in that bullet item that the use has been criticized. Overall, still very NPOV criticism by someone who has a personal issue with modal windows, an article with very little information about the subject itself. (Note: modal windows are used a lot in places where some other UI paradigm would work much better, I don't disagree with that. But a wikipedia article is supposed to be about whatever the subject is, not a crusade against the subject). —Preceding unsigned comment added by 192.100.124.218 (talk) 16:15, 30 March 2010 (UTC)

So the only concern regarding neutrality is undue weight? Feel free to add that missing information, or link to sources that report on those usages so we can work to include them in the article. Diego (talk) 10:40, 31 March 2010 (UTC)

NPOV tag added

I've added a NPOV tag to this article. Several editors have expressed concerns over this article, and I tend to agree with them. The biggest concern I have is that the overall tone of the article is adversarial. All aspects of the subject matter are placed under the "criticisms" category with all positive aspects of the subject being added only as defenses against its negatives. That's not neutral. I also have concerns about the shifting definitions of "mode" being used this article, including the habit of narrowing the definition to Jef Raskin's tight definition of "mode" when an "anti" case can be made, then applying that case to a broader definition. For example, according to Raskin's definition, a modal file dialog is not "mode" if the user explicitly requested to save and saving is the user's current focus (see Mode (computer interface)#Defintion), yet this article blurs that distinction to its detriment. Until these issues are resolved, I'd like to keep an NPOV tag on here. 98.232.121.163 (talk) 14:40, 31 May 2011 (UTC)

That's all well and good, and I support fixing any concerns about the structure and meaning of this article. But there's a deeper level in this tagging, and IMO there's not enough evidence to support it in this case. WP:NPOV requires representing all significant views that have been published by reliable sources.

So far the only rationale for the tag has been a gut feeling by some editors that positive and negative comment should be somehow balanced in order to be fair. But there are NO evidence at all that positive comment about modes has merit or should be expressed in this article. In that case, giving equal validity to the positive view would be against NPOV policy as an instance of undue weight or, worse yet, against wp:Verifiability.

For example, you say the article switches between Raskin's definition and a more general one. What is this broader definition you refer to? Certainly it's not sourced in the article, so we shouldn't rely on it; the only well-sourced formal definition of modes is Raskin's. Nor do I agree that this definition is used selectively in detriment of modes; the file dialog will be modal if it prevents work in the background window, as soon as the user tries to do anything other than saving a file. The user attention is not in the dialog window but in the process of saving a file (focus on the action, not the interface), thus the window itself is always modal. (The dialog would not be modal in the Raskin's sense while the user is dragging the window, for example; but that is a marginal case).

This battle has been fought again and again, and nobody could ever provide sources for a different portrayal of modes. I've tried hard to look for evidence of positive uses, and asked for it to anyone concerned, but none could be found. To the extent of my knowledge, everybody who has made a serious study of modes and modal has found them problematic. It's not bias to expose facts as reported by reliable sources, in especial when there are no existing sources that expose a different view. When the only significant viewpoint about a subject is negative, reporting it as negative can't violate NPOV. The overwhelming evidence by researchers is that modes and trouble go hand in hand. Until you present with reliable sources at least a somewhat solid case for a different viewpoint than the one currently hold by the article, I will ask to get the NPOV tag removed in the next days. Diego Moya (talk) 15:40, 31 May 2011 (UTC)

I provided such an example above, which you neglected to address. Raskin does not equate "mode" with "modal windows". However, you do. I say "you" because you are the primary editor who made those edits. Because you are using two different definitions for the same word (i.e. equivocating) that meets your personal feelings on the matter, I feel you are on the very edge of synthesis. Additionally, why is "Design Considerations" under "Criticism", when no actual criticism is taking place in that subsection? Why do you hold the "anti" cases held to a much lower standard than the "pro" cases? Why are the advantages ONLY presented as defenses against the negatives?

I'm going to switch this around on you, Diego. It is not my job to find you differing definitions of "mode", it is YOUR job (as you are the editor who made the changes to the article) to find a source that equates the definition that Raskin provides in Mode (computer interface) to all modal windows. You might also want to check the ownership stance at the door. 98.232.121.163 (talk) 15:53, 31 May 2011 (UTC)

Could you clarify which two meanings of mode are you implying? I don't understand why you say there are two distinct definitions, as I only see the Raskin's one as encompassing the whole topic. Would you explicitly expose what differences you find?

As for your accusation that I'm Owning the article, that would be true if anyone else would have cared to stay here to contribute and I had hindered them in some way. If you bother to review my participation in this article and related ones, I've always made requests that edits be made according to policy, have addressed the concerns people had and tried to improve the article in base of the provided feedback, and requested sources for the points that were raised against neutrality. It's not my fault that other editors never come again to help me improve the article. Maybe you're confounding ownership and stewardship?

And if you care to check the article, all the so-called anti stances are well referenced, which is the golden rule for inclusion, while unsourced pro weasel words and purported facts have not been removed even though they aren't verifiable. Diego Moya (talk) 16:19, 31 May 2011 (UTC)

Okay. Raskin's definition of "mode" was talking about things such as vi's "command mode" vs. "input mode", selecting tools from a palette in a paint program, and similar items. It was not talking about a dialog box that blocks its parent. Those are completely orthogonal concepts. In fact, the quoted definition seems to specifically exclude many kinds of modal windows: "An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." For many modal dialogs, the dialog is the user's center of attention and very few modal dialogs behave differently based on the system's current state. This entire definition of "mode" seems more geared toward "command modes" not "window modes". If you are going to apply this definition to "window modes" then you are going to need an exact source that equates them. Otherwise, you are synthesizing. (At the risk of being WP:POINTy, I've tagged a few unsourced weasel words of your own.) 98.232.121.163 (talk) 16:34, 31 May 2011 (UTC)

That's fair, you might have a point in that I assumed that modal windows, which create a different (blocked) state in their parent window when they appear (thus rejecting all the input that the parent window normally accepts), would fall under Rasking definition; specially since Rasking himself talks extensively about dialog windows in his book. Can you blame me for that obvious inference? Nobody ever challenged that point before; I'll try to find an explicit source making the same or equivalent connection, as I'm sure that books like The Humane Interface, About face and similar ones must explain what is a modal dialog in a way we can use in the article. Diego Moya (talk) 16:50, 31 May 2011 (UTC)

For now, I've found that Java describes modality of dialogs and categorize them between modeless and several types of modal. Blocking the parent dialog is the defining characteristic for modality. [1] I'll try to find more solid sources in scholarly work, but I think this direction is what's needed to defend that modality in dialog windows is referring to the same concept.

(The links provided for criticism don't use the Rasking definition anyway; they're orthogonal to this point you made, as they talk explicitly about dialog windows). Diego Moya (talk) 17:34, 31 May 2011 (UTC)

Careful there, Diego. What you are proposing (combining two different sources to come up with a third concept) is the very definition of synthesis. Window modality and application modality are different concepts. Having said that, I think the article is already looking much, much better. Some simple rearrangements of information went a long way to having a more NPOV-sounding article. I'm even willing to go so far to say that I'm okay with dropping the NPOV tag at this point. One last thing. I read every single one of the cited sources. Each one had very good, solid, and well-supported criticisms about error/confirmation popups, especially focus-stealing ones. However, these are only subset of modal dialogs, if the most abused. There seemed to be few, if any, concerns about other kinds of modal dialogs such as modal save dialogs, modal "about" dialogs, modal configuration dialogs, modal login dialogs, etc. In fact, the Jeff Atwood article [2] specifically recommends using wizards (which are universally modal windows). The article should try not to paint all modal windows with the same brush, especially when the cited sources are aimed only at a subset. 98.232.121.163 (talk) 18:13, 31 May 2011 (UTC)

This is why two editors are better than one. I appreciate the insight you give about different kinds of modal windows, and how the available sources may not refer to all them. I will review them with this idea in mind and try to improve the article accordingly; you're welcome to join me this task. I'd appreciate more reliable sources about those other kinds of non-error dialogs; the only one I've found of that kind was that about Lightboxes at web pages.

With respect to synthesis, we'll have to agree to disagree. IMO you're the one introducing a new separate idea by insisting that "window modality and application modality are different concepts"; if that assertion were made in the article I would tag it with . None of the sources I've found that address both UI modes and dialog windows give special treatment of dialogs as having a separate definition, so you haven't provided no sourced reason to believe that the same word "mode" as applied to computer interfaces is used with different meanings in the particular cases of commands and windows. Quite to the contrary, Raskin's T.H.E. is one of the major sources about modality in user interfaces, and it gives ample treatment of both command modes and notification dialogs without making any explicit remark that they should be treated differently. I'd say that the corpus of evidence so far supports my view better than yours.

Finally I'd like to emphasize that Mode (computer interface) already went through a similar re-arrangement, but I didn't get any feedback about the result. Would you mind giving it a quick read and point out any salient issues that may still stand out as unbalanced? I'd appreciate suggestions in particular about improving Mode errors section; while I feel that it's a fair summary of the topic it describes, it could benefit from more neutral language and a few more references for the way its ideas are expressed. Diego Moya (talk) 21:42, 31 May 2011 (UTC)

Layman Awareness

Still new at helping to maintain Wikipedia, but for those of us who have little knowledge about programming (which is probably why I stopped here first to learn about it), I was hoping that the terms "child" and "parent" could be linked to their definitions in the context of this article. Still learning how to do this or I would do that myself; such as, if I knew more about the difference between "modaless" and "modeless" I would just go ahead and make the correction - or, is it "modal less" and "model less"? I thank you, sincerely. MVD (talk) 11:22, 16 January 2009 (UTC)

You're absolutely right. I've added a link to the definition of "child nodes" in a tree, it's the best reference I've found to explain what is a child windows. Diego (talk) 17:25, 26 June 2009 (UTC)

Lightbox advert?

I have never heard of this library, there are tons of them and I often look at top 10 best JS apps for inspiration. So I have a strong feeling it is an ad. If I had to say what the quintessential modal was, I would say bootstrap modal. It is even called a modal. Not to mention that discontent towards modals is linked to bootstrap addiction. — Preceding unsigned comment added by 91.100.13.70 (talk) 10:45, 30 October 2015 (UTC)

I've seen "lightbox" used as a generic name for that design, rather than referring to any particular library. Maybe you'd want to rewrite the offending sentences in that way, removing emphasis on the library? Diego (talk) 11:37, 30 October 2015 (UTC)

External links modified (February 2018)

Hello fellow Wikipedians,

I have just modified 3 external links on Modal window. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100227095647/http://quince.infragistics.com/Patterns/Modal%20Panel.html to http://quince.infragistics.com/Patterns/Modal%20Panel.html
• Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx
• Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:15, 3 February 2018 (UTC)

Requested move 20 April 2024

Modal window → Modal (computing) – As User:Nnivi justly points out above, any user interface element can be a modal, not just windows. A popover, just to give one example, can also be modal or modeless. Another example, also given by Nnivi, is the drop-down list. 62.166.252.25 (talk) 14:17, 20 April 2024 (UTC) — Relisting. Natg 19 (talk) 21:49, 3 May 2024 (UTC)

• Oppose That may be true, but I don't see it reflected in the article's current content and sources. If someone expanded the article to include coverage of modal elements which aren't windows I would be more receptive to this proposal (though I suspect we would still find that these represent such a marginal share of the phenomenon that it would not justify renaming to a disambiguated title that is also more jargon-y). Colin M (talk) 20:08, 21 April 2024 (UTC)

We could rename this article to "modal container" or "modal widget", perhaps? Assuming the modal window is part of the containers subgroup of the graphical widget (graphical control element). Almost all instances of "modal window[s]" in this article could simply be renamed to the more general "modal container[s]" or "modal widget[s]" for the article to reflect its new title. Your "That may be true" is - to me - a key here, and my reason to suggest the rename; we should 'fix' this article to become more accurate and precise. --62.166.252.25 (talk) 06:15, 27 April 2024 (UTC)