Re: [whatwg] modal and modeless windows
On Sun, 2005-06-26 at 20:06 +0300, Karl Pongratz wrote: My point is, you can browse web documents, but you can't browse web applications, the browsing model is out of date. That is generally only the case (that you can't browse web applications) for web applications that are poorly written or use a web application framework that is poorly written, from a Web architecture point of view. A good web application will use GET and POST requests properly, will provide persistent and unique URLs for persistent, unique resources, and so on. A good web application framework will encourage developers to do this. I know of many web applications that are browsable. /Mike -- Michael Gratton, Software Architect. Quuxo Software http://web.quuxo.com/ signature.asc Description: This is a digitally signed message part
Re: [whatwg] modal and modeless windows
James, Sorry that I called you Graham :-). You distinguish between the two that a modal or a modeless window is something entirely different of what is the current browser window, so its not a window, it is a modal_window or a modeless_window. If you currently click on a link for a new html document you could open it in the same window, in a new window or in a new tab. This shouldn't be possible with modal or with modeless windows, the link for such windows should indicate that it is modal or modeless and will always open as new window, preferably without chrome. This way you don't break the browser back/next button in you web browser. So, all remains the same, except if you open a modal or a modeless window. The phishing scams problem. a.) Always indicate the URI in a status bar, which can't be disabled. Though the URI shouldn't be editable, only indicate it. b.) Don't allow to open modal/modeless windows from HTML email. c.) Only allow to connect the modal/modeless window to the same domain as of the document from where you opened the modal/modeless window. I.e. if you click a link on http://www.whatwg.org and you open a modal window, then the content in the modal window can only be loaded from http://www.whatwg/org/modal_1.htm, it wouldn't be possible to establish a connection to a different domain, i.e. to http://www.ufo.com/modal_1.htm. Proving a simple, fixed, navigational paradigm isn't out of date, it's essential to the usability of the web. I don't think it breaks something because you don't touch the web browser back/next button in window, it only doesn't exist in modal/modeless windows, which are different from window. is the WHATWG mailing list subscription form an example of a document or of an app? I would say its a mini app, and the approach you use now, to browse to it, is legal, though I use it as the most trivial example. Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. Karl J. Graham wrote: On Sun, 26 Jun 2005, Karl Pongratz wrote: Graham, (James actually :) ) My point is, you can browse web documents, but you can't browse web applications, the browsing model is out of date. How do you distinguish the two? If we agree (we may not, I don't think you mentioned this) that it's undesirable to let web sites disable features such as the back button (and, because of phishing scams, this is certainly the direction that UA vendors are moving in - for example chromeless windows are likely to become extinct in the near future) there needs to be a way to distinguish between a web site and a (trustworthy) web app - is the WHATWG mailing list subscription form an example of a document or of an app? You can certianly browse to it and away from it but it has some app-like functionality. If we let that page disable the back button presumably there'll be no way to stop any other site from doing so and we'll suffer all the UI problems I previously described. Proving a simple, fixed, navigational paradigm isn't out of date, it's essential to the usability of the web. If you want to introduce technology that allows authors to break that model in situations where the it doesn't make sense [1] you have to make _really_sure_ you don't allow them to break it anywhere else. [1] These are rarer than people believe - in general you should try to write applications that can deal with the back button and other browser-provided navigation, rather than break when it is used. .
Re: [whatwg] modal and modeless windows
Karl Pongratz wrote: Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. If you have AJAX, why not submit form data via XMLHttpRequest rather than changing the current URL? That way, there is no back button within the context of navigating the application.
Re: [whatwg] modal and modeless windows
James Graham wrote: Matthew Raymond wrote: Karl Pongratz wrote: Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. If you have AJAX, why not submit form data via XMLHttpRequest rather than changing the current URL? That way, there is no back button within the context of navigating the application. Indeed, that seems like a reasonable solution that doesn't require multiple types of window (and fits the general HTTP model quite well since a single web-app can be seen as a single resource accessible through a single URL). There are various other pieces of technology in the spec that make this sort of thing even easier (server-sent DOM events, for example, so a system for the server to push data to the client as necessary is easy to set up). Of course all this javascript the downside that accessibility is hard to get right. Well, if you have a Wizard with 6 steps done by AJAX, how do you explain to the user that he/she can't anymore use the web browser back/next button to navigate through the Wizard? Imagine you are at Wizard step 6, have filled in a ton of form fields and accidentally click the web browser back button, it will lead you somewhere, maybe to a resource you have visited before the Wizard resource. Does that sound as a logical browsing model which a user will ever understand? Beside that, how many desktop applications do you know which don't use modal and modeless windows? I know many without a back/next button, but none without modal window support comes into my mind. Is the web browser damned to limit it to back/next only? Will the only alternative be Java Webstart, Microsofts XAML or Flash to get a desktop like user interaction model? Karl
Re: [whatwg] modal and modeless windows
On 6/27/05, Karl Pongratz [EMAIL PROTECTED] wrote: ... Beside that, how many desktop applications do you know which don't use modal and modeless windows? ... The fact that some applications use modal windows does not necessarily mean that it is a good idea. In fact, all the books I've read on interface design say that modal windows are bad idea. At least they are used mostly in the bad way. Regards, Rimantas -- http://rimantas.com/
[whatwg] Re: modal and modeless windows
Mark, I appreciate that Xforms supports modal and modeless messages, yet I miss it in the web browser. I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. You can do the same without modal windows, the traditional approach, see i.e. Views and Forms: Principles of Task Flow for Web Applications Part 1 (Bob Baxley) http://www.boxesandarrows.com/archives/views_and_forms_principles_of_task_flow_for_web_applications_part_1.php Though I believe the modal window approach would be much cleaner and saver, maybe Bob Baxley would have chosen that way, if modal windows existed. Karl Mark Birbeck wrote: Karl, [I'm not on the WhatWG list, so this will probably bounce.] I had a short look at the webforms and web applications specification at whatwg.org, I didn't find anything about modal and modeless windows. If there is anything to improve for html, xhtml, xforms and compound documents, then, in my opinion, the first missing feature that comes into my mind is the lack of modal and modeless windows. XForms does already have modal and modeless messages, and I know that both X-Smiles and formsPlayer have implemented them in such a way that the message itself can contain other form controls. (I don't know about other implementations, but my guess is they probably do, too.) In other words, you can have a little sub-form that updates the main instance data, but appears to the user as a separate 'window'. The only difference then between modal messages and modeless ones are that modal messages block execution until they have been closed, whilst modeless ones can happily sit on top of the main form. Note also that once again we get a much better model in XForms, since actually what we are talking about is the behaviour of an abstract concept -- a 'message' -- which will act differently on different platforms. We don't say use some method call on the document or window object, as we have to do in current solutions, but which is very difficult to make accessible. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: [EMAIL PROTECTED] t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/ .
Re: [whatwg] modal and modeless windows
Karl Pongratz wrote: Well, if you have a Wizard with 6 steps done by AJAX, how do you explain to the user that he/she can't anymore use the web browser back/next button to navigate through the Wizard? Imagine you are at Wizard step 6, have filled in a ton of form fields and accidentally click the web browser back button, it will lead you somewhere, maybe to a resource you have visited before the Wizard resource. Does that sound as a logical browsing model which a user will ever understand? Actually, the logical thing would be to have each step as a separate AJAX-based web page, where changes to fields are reported back to the server. The server then keeps track of the values of the fields for each step and can repopulate the fields when you use the forward and back buttons. No modal windows necessary. Beside that, how many desktop applications do you know which don't use modal and modeless windows? In most cases, if you show me an application with a modal window, I'll show you an application that needs to do away with a modal window. The use cases for applications that truly need modal windows probably overlaps the use cases for XULRunner-base applications quite nicely. I know many without a back/next button, but none without modal window support comes into my mind. Considering that back/next buttons were invented later, that proves little. For instance, any kind of preference or settings dialogs you can think of could be put in a collapsible sidebar. I personally worked on a project where they had forward and back buttons for three different levels. Wizards are a perfect example of back/next as well, and there are plenty of those. Is the web browser damned to limit it to back/next only? Will the only alternative be Java Webstart, Microsofts XAML or Flash to get a desktop like user interaction model? I can't think of much you can't do with these technologies that you can't do with existing web app technology. It's simply faster or has more native features. For instance, menus are easily simulated by DHTML-based web apps. Similarly, you could easily simulate modal windows by using a few div elements and disabling various controls. Considering modal-anything is generally considered bad UI, I don't think we should encourage it, especially when it's so incompatible with current browser usage.
Re: [whatwg] Re: modal and modeless windows
Karl Pongratz wrote: I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. Where do you need modal windows in this model? Someone clicks on the edit link to bring up an address editing page in a new window. You edit, then click save or cancel, which closes the window. AJAX and server-sent DOM events update the original window when you save. If the address is deleted or altered, server-sent DOM events can update the editing window to act accordingly. (In the event of a deletion, for instance, the editing window could change to a simple page saying This address has been deleted.) Since the dialog is not modal, you can edit multiple addresses at the same time, and you can even do so while the buddy you're sharing the address book with is editing it. As far as links go, the newly created address editing windows don't have a previous window because they were just spawned, and if they don't need links to load inside the window, then don't put any or have them spawn new windows. So I ask you, for this example, where is the benefit of modal windows?
Re: [whatwg] modal and modeless windows
On 6/27/05, Karl Pongratz [EMAIL PROTECTED] wrote: ... In most cases, if you show me an application with a modal window, I'll show you an application that needs to do away with a modal window. The use cases for applications that truly need modal windows probably overlaps the use cases for XULRunner-base applications quite nicely. That's new to me. Can we live without modal windows from now? Is that somewhere written? ... Not exactly this way, but you may want to check: Chapter 10 Eliminating Excise Chapter 11 Navigation and Inflection Chapter 30 Using Dialogs Chapter 34 Notifying and Comfirming in About Face 2.0 The Essentials of Interaction Design by Alan Cooper Robert Reimann, Willey Publishing, 2003 6-5 Letter from a User in The Human Interface - New Direction for Designing Interactive Systems by Jef Raskin, Addison-Wesley, 2005 Also the classics: Design of Everyday Things by Donald A. Norman and Inmates are Runing the Asylum by Alan Cooper won't hurt :) Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Re: modal and modeless windows
Matthew Raymond wrote: Karl Pongratz wrote: I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. Where do you need modal windows in this model? Someone clicks on the edit link to bring up an address editing page in a new window. You edit, then click save or cancel, which closes the window. AJAX and server-sent DOM events update the original window when you save. If the address is deleted or altered, server-sent DOM events can update the editing window to act accordingly. (In the event of a deletion, for instance, the editing window could change to a simple page saying This address has been deleted.) Since the dialog is not modal, you can edit multiple addresses at the same time, and you can even do so while the buddy you're sharing the address book with is editing it. As far as links go, the newly created address editing windows don't have a previous window because they were just spawned, and if they don't need links to load inside the window, then don't put any or have them spawn new windows. So I ask you, for this example, where is the benefit of modal windows? I am using the current approach you describe, and as long as you have only a single additional window (the edit form) open it wouldn't be a problem, except if you want the user to explicitly complete a task, then modal would be required. In case of the addresses modal may not be required, it depends if you want to allow the user to delete a contact while the same contact is open in the edit form. It probably wont harm something in this case but it may in others. The problem starts in the edit form, if you want yet to open another window, lets say you want to attach a file to the address which is opened in the edit window, within the opened edit window you open a HTML File Manager. So you have 3 windows open, the address view in the main web browser window, the edit form in a new window (without chrome) and the File Manager in another new window (without chrome). Wouldn't you use at least a modal window in case when you open the File Manager, if modal Windows would exist? The File Manager is just one case, I face this problem many times where for an external edit form it would be convenient to open a modal sub window. So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows.
[whatwg] RE: modal and modeless windows
Karl, [I'm not on the WhatWG list, so this will probably bounce.] I had a short look at the webforms and web applications specification at whatwg.org, I didn't find anything about modal and modeless windows. If there is anything to improve for html, xhtml, xforms and compound documents, then, in my opinion, the first missing feature that comes into my mind is the lack of modal and modeless windows. XForms does already have modal and modeless messages, and I know that both X-Smiles and formsPlayer have implemented them in such a way that the message itself can contain other form controls. (I don't know about other implementations, but my guess is they probably do, too.) In other words, you can have a little sub-form that updates the main instance data, but appears to the user as a separate 'window'. The only difference then between modal messages and modeless ones are that modal messages block execution until they have been closed, whilst modeless ones can happily sit on top of the main form. Note also that once again we get a much better model in XForms, since actually what we are talking about is the behaviour of an abstract concept -- a 'message' -- which will act differently on different platforms. We don't say use some method call on the document or window object, as we have to do in current solutions, but which is very difficult to make accessible. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: [EMAIL PROTECTED] t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Re: [whatwg] Re: modal and modeless windows
Karl Pongratz wrote: Matthew Raymond wrote: So I ask you, for this example, where is the benefit of modal windows? I am using the current approach you describe, and as long as you have only a single additional window (the edit form) open it wouldn't be a problem, except if you want the user to explicitly complete a task, then modal would be required. I'm going to be lazy and ask you to provide the use case, since you're the one claiming one exists in the first place. In case of the addresses modal may not be required, it depends if you want to allow the user to delete a contact while the same contact is open in the edit form. Simple way around that. Put the delete button in the editing window. It probably wont harm something in this case but it may in others. /me coughs in a manner that sounds very much like the words use case. The problem starts in the edit form, if you want yet to open another window, lets say you want to attach a file to the address which is opened in the edit window, within the opened edit window you open a HTML File Manager. So you have 3 windows open, the address view in the main web browser window, the edit form in a new window (without chrome) Every indication is that chromeless windows are on their way out. and the File Manager in another new window (without chrome). Wouldn't you use at least a modal window in case when you open the File Manager, if modal Windows would exist? Assuming the address can only be deleted by opening it in an address editing window and pressing delete, you have no use case in this situation, since the address can't be deleted until you return from the file manager. I would consider that this might be a problem in other situations, but I wonder if there aren't simple workarounds for it. The File Manager is just one case, I face this problem many times where for an external edit form it would be convenient to open a modal sub window. So your use case for modal windows is that there are many convenient situations where you'd want to open a modal window... So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows. Yeah, hacks like this run the risk of conflicting with native UI conventions, I'll give you that. However, it is widely accepted that modal UI is to be avoided anyway.
