[whatwg] Re: modal and modeless windows

Karl Pongratz wrote:
> Matthew Raymond wrote:
>>   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.

     Well, you have a web page you have a link to on your desktop that
contains info you need for the wizard. Your computer is set to open URLs
in existing windows. You realize your mistake and go to hit the back
button, but it's not there.

> 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.

     You're the one who keeps bringing up the chromeless window.
Personally, I'm greatly annoyed by web apps that are not
back-button-aware. I can't count all the times I've gone from a listing
page to a page for an item in the listing, then pressed the back button
only to find that I have to press the actual link that says "return to
the listing" to get back.

     People know where the back and next buttons are. They use them all
the time. Why would you not design your web app to take advantage of a
piece of UI that the user is so familiar with?

>>>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.

     (Note that I was explaining that file dialogs didn't have to be
separate modal windows in user agents. I was not suggesting that web
standards /require/ non-modal, in-window file dialogs.)

> 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.)?

     I'm not sure what you mean. User agents are free to use modal
dialogs all they want, because HTML doesn't specify that things like
file dialogs be non-modal. So if someone is trying to upload a file, the
method they use to locate the file is not defined by HTML. If the user
agent vendor feels that a modal file dialog is most appropriate, so be it.

     Color pickers aren't in HTML, but perhaps they should be:

| <label>Foreground Color: <input type="color" name="foreground"></label>

     Now, I've seen quite a few color pickers that /aren't/ modal, that
are either flat controls or temporary pop-up style controls like a
combobox. Therefore, for the markup above, the implementation is the
domain of the UA, not HTML.

     That's important to note. HTML isn't the place for behavioral
features. At the very least we should probably be talking about this
specifically in the context of Javascript, in which case we should be
talking about how a web app might degrade with Javascript turned off.

     If you're talking about DHTML color pickers, I think the
combobox-style approach is pretty well established in that case.

     As far as subforms, wizards are probably a bad use case. Granted,
I've seen subforms, but I've also seen tree controls that do the exact
same thing. But let's assume there is a specific use case for this anyway.

     First of all, if you allow for chromeless windows, and you can
simple disable all form controls on the parent wizard window when the
user presses the button to go to the subform. When the subform returns,
you would then reenable all controls. All the modal state really does is
keep the user from putting the parent in front of the child, or from
terminating the parent, but I think we're in "stupid user" territory here.

     Just had a thought. You could use <switch> and some scripting to
avoid the browser history. Just have the entire wizard inside the
<switch> element:

| <switch>
|   <section id="s1">
|     <h>Wizard Page 1</h>
|     <p>...Content for Page...</p>
|     <a href="javascript:document.getElementById('s2').setActive()">
|       Next
|     </a>
|   </section>
|   <section id="s2">
|     <h>Wizard Page 2</h>
|     <p>...Content for Page...</p>
|     <a href="javascript:document.getElementById('s1').setActive()">
|       Previous
|     </a>
|     <a href="javascript:document.getElementById('s3').setActive()">
|       Next
|     </a>
|   </section>
|   <section id="s3">
|     <h>Wizard Page 3</h>
|     <p>...Content for Page...</p>
|     <a href="javascript:document.getElementById('s2').setActive()">
|       Previous
|     </a>
|     <button name="finish">
|       Finish
|     </button>
|   </section>
| </switch>

    This wouldn't solve the subform problem, though.

    Bottom line, though, is that if the parent window is chromeless, you 
can simply go to the subform instead of bringing it up in a new window. 
It's functionally the same without having to worry about multiple windows.

>>>>>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.

    Not entirely.

> If that doesn't make it clear I 
> am afraid that you don't want to understand and I am just wasting my time.

    If you can't show definitively why modal windows are superior UI and 
worth the possible security and ad-related headaches, then you are 
wasting your time. Not that I'm not listening. I can see that modal 
dialogs are nice for specific situations. I just don't see those 
situations popping up all that much in a non-native application.

Received on Wednesday, 29 June 2005 18:13:10 UTC