W3C home > Mailing lists > Public > www-forms@w3.org > June 2005

Re: [whatwg] Re: modal and modeless windows

From: Karl Pongratz <karlhp@karlhp.com>
Date: Tue, 28 Jun 2005 22:42:21 +0300
Message-ID: <42C1A81D.70209@karlhp.com>
To: Matthew Raymond <mattraymond@earthlink.net>
CC: WHAT WG List <whatwg@whatwg.org>, www-forms@w3.org, dean@w3.org

Matthew Raymond wrote:

> Karl Pongratz wrote:
>
>> Matthew Raymond wrote:
>>
>>>  Did it occur to anyone that this is all hostile to the user? You 
>>> prevent the user from accessing controls for browser (buttons, 
>>> menus, et cetera). You prevent the user from going to another 
>>> domain. You block their access to an underlying window. This all 
>>> smacks of "let's control the users, because the users are stupid".
>>
>>
>> I wouldn't call users stupid, I would call web browsers stupid if 
>> they are not capable to let the user complete a task in the most 
>> productive and logical manner.
>
>
>    How do modal windows let a user complete a task in a more 
> productive way than a non-modal window? If you had two identical 
> windows, except one is modal and one isn't, how would they be function 
> differently from one another if the user never bothers to click on the 
> parent window? Being modal has nothing to do with the content of 
> functionality of the new window, and has everything to do with 
> preventing the user from interacting with the parent window, which is 
> obviously not designed to be used while another window is up, or you 
> wouldn't need the modal window in the first place.

Thanks for explaining what a modal window is.

>
>    Now, consider an AJAX app, using the address example. In the main 
> window, you have a list of addresses. This is the Address-List state. 
> When you click on an item to edit it, the application switches to the 
> Address-Edit state and changes the UI to reflect what you can do in 
> this new state. You edit the fields, then press "save", "delete" or 
> "cancel". The appropriate operation is performed, and the state 
> returns to Address-List with the UI being dynamically changed 
> accordingly. The UI is managed by AJAX rather than a series of web 
> documents, so there's no browser history to worry about, and even if 
> you do hit the back button or go to another URL, the state and other 
> information can be stored on the server, so that when you go back to 
> the web app, the state is completely restored. (Actually, thinking 
> about it, you could use AJAX to fetch HTML and implant it into the 
> current document to change the UI.)

Let's take again the Wizard example, I think we had it already. I don't 
want to do the overhead to start synchronizing the client and server 
state, and I do not understand what sense it makes to have duplicate 
Back and Next buttons, one pair in the web browser and another pair 
inside the wizard. And, there is no need to restore the state, why 
should I do this overhead, open the wizard in a new window, and complete 
it. Though, we said that the wizard is not modal, but in a chromless window.

>> However, I thought we are talking about web applications, or do you 
>> want start reading your newspaper within Dreamweaver, a Color Picker 
>> or your File Manager? Is that what you intend :-) ?
>
>
>    (I'm not exactly sure what you mean, but I'll take a stab at it.)
>
>    Why do we need a modal file dialog at all, especially in a browser? 
> Browsers can view files and directories (see Internet Explorer), so 
> what's the point. Just have "Open File..." take you to the system 
> directory in the browser and add some associated panes for the 
> directory tree, et cetera. Then you can open multiple files in tabs 
> and still have the last directory I was on open.

Take the wizard I mentioned above, in a chromeless window. Within the 
Wizard you need
a.) to open a File Manager and
b.) to open a Color Picker and
c.) to open a Subform (due to the complexity of the Wizard)
The Local File Manager doesn't work in my case, in case that it works 
for you, there is still b.) and c.)
Of course I could just open another chromeless window but if I remember 
correct modal windows were invented to handle this cases. Anything wrong 
to use modal windows in a.), b.) and c.)?

>
>>>> The case where you require modal windows may be rare, yet they are 
>>>> extremely useful in those cases, I remember they are on the web 
>>>> applications wish list at "Joel on software" as well, 
>>>> http://www.joelonsoftware.com/oldnews/pages/June2004.html , section 
>>>> Thursday, June 17, 2004.**
>>>
>>>
>>>   Yeah, but he really doesn't [say] why. I was hoping he'd have a 
>>> use case in there somewhere...
>>
>>
>> Are you sure you need a more detailed use case?
>
>
>    There isn't a use case at that URL, so far as I can tell.

I think the above wizard example makes it clear why chromeless modeless 
and modal windows have there advantage. If that doesn't make it clear I 
am afraid that you don't want to understand and I am just wasting my time.

>
>
> .
>
Received on Tuesday, 28 June 2005 19:42:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:01 GMT