- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 28 Jun 2005 14:15:36 -0400
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. 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.) > 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. >>>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.
Received on Tuesday, 28 June 2005 11:15:36 UTC