[whatwg] Re: modal and modeless windows

Matthew Raymond wrote:

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

The back button is great, for documents. Personaly I find the back 
button annoying in the case that it returns me to a page where it 
doesn't make sense, which is not the case for documents but for web 
applications. And I don't remember how many times the web browser back 
button has been called the evil of web apps in related discussion. 
Hence, chromeless windows give me the chance to unlock from the broswer 
back/next button and the browser history.

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

It should be left to the developer if a web application can degrade or 
not if Javascript is turned off. In many cases it wont simply not be 
allowed to run an application if javascript is turned off. That's 100% 
legal I think.

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

Please leave developers decide what kind of color picker they want to use.

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

I am still convinced that chromeless windows for forms/applications have 
advantages over the traditional approach and that the addition of modal 
windows would just make it better. I respect that you would do it 
different, though I think developers should be free to choose the 
approach they think is better for there users. I am using chromeless 
windows in a number of places and as far as I can tell it just works 
perfect for the users..
However, I decided to do a more detailed description (browsing 
scenarios) for the approach you and others would go for and the approach 
I would go, by listing the pros and cons for each different approach, I 
will do that in detail, so it may take some time (Jul/Aug/Sep?, have yet 
other works to do).

Thanks to all for your input so far, hope to talk again when the 
different scenarios are ready.

Karl

>
> .
>

Received on Thursday, 30 June 2005 00:55:21 UTC