- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 01 Jul 2005 09:10:01 -0400
Hallvord Reiar Michaelsen Steen wrote: > On 1 Jul 2005 at 13:27, Karl Pongratz wrote: >>>click "edit" in my fancy address book application, a modal window pops >>>up, I want to go to the tab where my E-mail lives to copy the address I >>>wanted to put in my address book and ... ouch, can't get to the E-mail >>>because I use an integrated browser/mail client application and the modal >>>dialog blocks access to all the tabs. >> >>If you want to copy an email address you will have a problem with any web >>app I think, traditional and Ajax based once. > > Perhaps you misunderstood that? I as a user expect to be able to > switch between tabs to copy and paste information between different > pages. A modal dialog breaks that. Yeah, and I can't really see a way around that. If you can change the z-order so that the parent window is above the child, you've already violated one standard UI convention regarding modal windows. So even if the modal nature of the dialog only applied to the HTML viewing area, back/next buttons and the address bar (and bookmarks, et cetera), which violates UI conventions right there, you'd still have the z-order issues. So the simplest way to go is to have chromeless windows instead of modal ones. However, in the scenario where chromeless windows are permitted, we still have to deal with tricks involving simulated chrome designed to trick the user and other stuff. We definitely need to decide how to handle chromeless windows. >>If you want to do that in a >>nice way you may need to use at least chromeless windows, yet you could >>use modal windows from the already opened chromeless windows, then you can >>access your main page even if a modal window is active. > > I see, you expect your app to live in a window of its own and not in > a tab. Only to get rid of browser UI like back button and address > bar? > LOL, I'm your web app's user from hell, I routinely duplicate windows > to go back in history and see what I wrote and if I use IE and you > open a poup without address bar I view properties and copy the > address just to get my normal UI back. I know it is hard to keep up > with such behaviour from the backend, but I expect your app to > manage. Thank you. It's important to point out that users may not be using chrome by accident. This is what I meant by "user hostile" in previous messages. Modal dialogs block access to the UI that the user needs to control the browser. The whole point is to limit user control so that your application doesn't need to be as robust and doesn't have to deal with multiple input scenarios. If the user MUST do something a specific way, then you don't have to write code for any other way the user might try to accomplish the task. It's shifting part of the cost of development from the developer to the user. > Is it possible to keep the two discussions chromeless windows and > modal dialogs separate, please? If you're talking about modal dialogs, chromeless windows have to come up because modal dialogs must be chromeless. However, the modal conversation can be put on hold until we figure out whether chromeless windows are acceptable in one form or another.
Received on Friday, 1 July 2005 06:10:01 UTC