Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
On Dec 12, 2014, at 2:26 PM, David Lyle dkly...@gmail.com wrote: works for me, less complexity +1 Sorry I’m a bit late to the game here… +1 to this though from my perspective! Liz On Fri, Dec 12, 2014 at 11:09 AM, Timur Sufiev tsuf...@mirantis.com wrote: It seems to me that the consensus on keeping the simpler approach -- to make Bootstrap data-backdrop=static as the default behavior -- has been reached. Am I right? On Thu, Dec 4, 2014 at 10:59 PM, Kruithof, Piet pieter.c.kruithof...@hp.com wrote: My preference would be “change the default behavior to 'static’” for the following reasons: - There are plenty of ways to close the modal, so there’s not really a need for this feature. - There are no visual cues, such as an “X” or a Cancel button, that selecting outside of the modal closes it. - Downside is losing all of your data. My two cents… Begin forwarded message: From: Rob Cresswell (rcresswe) rcres...@cisco.commailto:rcres...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: December 3, 2014 at 5:21:51 AM PST Subject: Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org +1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
While clicking off the modal is relatively easy to do my accident, hitting Esc or ‘X’ are fairly distinct actions. I don’t personally think there is any need to warn the user in that instance :) Rob On 3 Dec 2014, at 22:30, Aaron Sahlin asah...@linux.vnet.ibm.commailto:asah...@linux.vnet.ibm.com wrote: I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
Hi Aaron, The only way to combine 2 aforementioned solutions I've been thinking of is to implement David's solution as the 4th option (in addition to true|false|static) on a per-form basis, leaving the possibility to change the default value in configs. I guess this sort of combining would be as simple as just putting both patches together (perhaps, changing a bit David's js-code for catching 'click' event - to work only for the modal forms with [data-modal-backdrop='confirm']). On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin asah...@linux.vnet.ibm.com wrote: I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
The more I think on it. I agree with Rob Cresswell comment While clicking off the modal is relatively easy to do my accident, hitting Esc or 'X' are fairly distinct actions. While there is nothing wrong with warning the user that they will lose data after they clicked the 'x' / 'esc'... That was a deliberate action by them. So might be over engineering this. My vote is to just keep it simple and go with changing the default behavior to 'static'. On 12/4/2014 8:08 AM, Timur Sufiev wrote: Hi Aaron, The only way to combine 2 aforementioned solutions I've been thinking of is to implement David's solution as the 4th option (in addition to true|false|static) on a per-form basis, leaving the possibility to change the default value in configs. I guess this sort of combining would be as simple as just putting both patches together (perhaps, changing a bit David's js-code for catching 'click' event - to work only for the modal forms with [data-modal-backdrop='confirm']). On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin asah...@linux.vnet.ibm.com mailto:asah...@linux.vnet.ibm.com wrote: I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behaviour to 'static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.com mailto:tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
Just throwing in my two cents: Multiple times, I've lost typed in data in Horizon because I've accidentally pressed escape without thinking (I use Vim, so pressing escape when I'm done typing is second nature). While clicking the 'x' button is often deliberate, pressing escape can be accidental (either through habit or through accidentally pressing the key). Best Regards, Solly Ross - Original Message - From: Aaron Sahlin asah...@linux.vnet.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, December 4, 2014 12:00:13 PM Subject: Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon The more I think on it. I agree with Rob Cresswell comment While clicking off the modal is relatively easy to do my accident, hitting Esc or ‘X’ are fairly distinct actions. While there is nothing wrong with warning the user that they will lose data after they clicked the 'x' / 'esc'... That was a deliberate action by them. So might be over engineering this. My vote is to just keep it simple and go with changing the default behavior to 'static'. On 12/4/2014 8:08 AM, Timur Sufiev wrote: Hi Aaron, The only way to combine 2 aforementioned solutions I've been thinking of is to implement David's solution as the 4th option (in addition to true|false|static) on a per-form basis, leaving the possibility to change the default value in configs. I guess this sort of combining would be as simple as just putting both patches together (perhaps, changing a bit David's js-code for catching 'click' event - to work only for the modal forms with [data-modal-backdrop='confirm']). On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin asah...@linux.vnet.ibm.com wrote: I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
The confirmation modal on the top of the other modal is weird and cumbersome. I think disabling clicking outside space (staic backdrop) is the right way to go. Anton On Tue, Dec 2, 2014 at 8:30 PM, Thai Q Tran tqt...@us.ibm.com wrote: I like David's approach, but having two modals (one for the form, one for the confirmation) on top of each other is a bit weird and would require constant checks for input. We already have three ways to close the dialog today: via the cancel button, X button, and ESC key. It's more important to me that I don't lose work by accidentally clicking outside. So from this perspective, I think that having a static behavior is the way to go. Regardless of what approach we pick, its an improvement over what we have today. [image: Inactive hide details for Timur Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The default behavior of modal]Timur Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstr From: Timur Sufiev tsuf...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 12/02/2014 04:22 AM Subject: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon -- Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] *https://review.openstack.org/#/c/113206/* https://review.openstack.org/#/c/113206/ [2] *https://review.openstack.org/#/c/23037/* https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
I like David's approach, but having two modals (one for the form, one for the confirmation) on top of each other is a bit weird and would require constant checks for input. We already have three ways to close the dialog today: via the cancel button, X button, and ESC key. It's more important to me that I don't lose work by accidentally clicking outside. So from this perspective, I think that having a static behavior is the way to go. Regardless of what approach we pick, its an improvement over what we have today. From: Timur Sufiev tsuf...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 12/02/2014 04:22 AM Subject:[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
I would agree in principle - keeping the user from losing data with accidental side clicks is important, and having a modal on a modal is not a great experience. We could make the closing of the modal upon outside click just contextual on whether or not the user has entered data / modified anything, but that will likely just seem inconsistent to the user. I’d vote for the static behavior and rely on the explicit close options to allow the user to exit out (esc, cancel, and [x]). Michael On Dec 2, 2014, at 8:30 AM, Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote: I like David's approach, but having two modals (one for the form, one for the confirmation) on top of each other is a bit weird and would require constant checks for input. We already have three ways to close the dialog today: via the cancel button, X button, and ESC key. It's more important to me that I don't lose work by accidentally clicking outside. So from this perspective, I think that having a static behavior is the way to go. Regardless of what approach we pick, its an improvement over what we have today. graycol.gifTimur Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstr From: Timur Sufiev tsuf...@mirantis.commailto:tsuf...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: 12/02/2014 04:22 AM Subject: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
